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ABSTRACT 

Traditionally,  the  design  and  mplementatlon  of  a 
conventional  database  system  begins  with  the  choice  of  a 
data  model  followed  by  the  specification  of  a  model-based 
data  language.  Thus,  the  database  system  Is  restricted  to  a 
single  data  model  and  a  specific  data  language.  An 
alternative  to  this  traditional  approach  to  database-system 
development  Is  the  multl-llngual  database  system  (MLOS). 
This  alternative  approach  affords  the  user  the  ability  to 
access  and  itanage  a  large  collection  of  databases,  via 
several  data  models  and  their  corresponding  data  languages, 
without  the  aforementioned  restriction. 

In  this  thesis,  we  present  a  methodology  for  supporting 
network  (CODASYL)  database  management  on  the  mlds. 
Specifically,  we  design  an  Interface  which  translates 
CODASYL-DML  Statements  Into  ABDL  reguestSt  >^e  describe  the 
data  structures,  the  control  mechanisms*  and  the  functions/ 
procedures  necessary  to  Implement  such  a  system. 
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I.   XUIfiQOUCIIQll 

A,   MOTIVATION 

During  the  past  two  decades,  the  design  and 
ImpiefTientation  of  database  systems  has  followed  a  rather 
predictable  path.  The  sequence  of  events  In  the  typical 
approach  has  been  to  decide  on  a  data  model,  specify  a 
model-based  lanquaqe,  and  ultimately,  develop  a  system  for 
controlling  and  executing  the  transactions  written  in  the 
data  language.  This  approach  to  database  system  development 
has  resulted  in  an  abundance  of  homogeneous  database 
systems  each  of  which  restricts  the  user  to  a  single  data 
model  and  a  specific  model«based  data  manipulation  language. 
Some  examples  of  systems  developed  using  this  approach 
include  IBM's  Information  Management  System  (IMs5  which 
supDorts  only  the  hierarchical  data  model  and  Data  Language 
I  (DL/I),  Sperry  Univac's  DMS-llOO  which  supports  just  the 
network  data  model  and  the  CODASYL  Data  Manipulation 
Language,  and  IBM's  SQL/Data  System  which  supports  solely 
the  relational  data  model  and  the  Structured  English  Query 
Language  (SQL), 

An  unconventional  approach  to  the  problem  of  database 
management  system  development,  referred  to  as  the  Multi- 
lingual Database  System  (mldS)  CRef,  iJ,  eliminates  the 
restrictions   mentioned  above.   The  MLDS  would  give  the  user 
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the  ability  to  access  and  manage  a  large  collection  of 
databases,  using  several  data  rriodels  and  their  corresponding 
data  languages.  The  design  goal  of  the  mlds  project  Is  tne 
developn^ent  of  a  system  that  is  accessible  via  a 
hlerarchlcal/DL/I  Interface,  a  relational/SQL  Interface,  a 
networK/CODASYL  Interface,  and  an  entl tv-relatlonshlp/Daplex 
Interface,  Such  a  system  would  function  as  If  It  were  a 
heterogeneous  collection  of  database  systens  Instead  of  a 
single  model,  single  language  system. 

Some  of  the  advantages  of  a  MLDS  are  the  reuseablllty  of 
database  transactions  developed  on  a  conventional  system, 
economy  and  effectiveness  of  hardware  upgrades  (since  we  now 
upgrade  just  one  system  Instead  of  a  number  of  different 
systems),  and  Its  ability  to  support  a  variety  of  databases 
built  around  any  of  the  well-known  data  models.  Thus,  there 
Is  ample  motivation  for  developing  such  a  system  as  the 
MLDS, 

B,   TH£  SYSTEM  ORGANIZATION 

In  order  to  realize  the  above  capabilities,  the  mlds 
must  be  supported  by  an  underlying  database  system  that  Is 
both  fast,  efficient,  and  effective,  if  these  criterion  are 
not  met,  then  the  Interfaces  being  developed  for  the  MLDS 
may  be  rendered  useless.  Hence,  It  Is  important  that  the 
kernel  data  model  and  kernel  data  language  (the  underlying 
model  and  language  for  the  system)  be  supported  by  a  high- 
performance   and   hlgh-caoaclty  database  system.   Currently, 

12 


the  attribute-based  data  model  and  attribute-based  data 
language  are  the  underlying  model  and  language  of  a  system 
Which  Is  referred  to  as  the  Multl-bacicend  Database  System 
(MBDS),  In  this  section,  we  provide  an  overview  of  both  tne 
MLDS  and  tne  MBDS  to  enhance  the  readers  understanding  of 
the  entire  Multl-Llngual  Database  System, 
1.  ihg.   Multi-Llosual  OatabAsa  Svstaa 

Figure  1  Illustrates  the  complete  structure  of  the 
multl-llngual  database  system.  The  user  Interacts  with  the 
system  through  the  language  Interface  layer  (LID,  using  a 
chosen  user  data  model  (UDM)  to  Issue  transactions  written 
in  a  corresponding  model-based  user  data  language  (UDL), 
The  LIL  routes  the  user  transactions  to  the  Kernel  maoplng 
system  (KMS),  The  Kms  then  performs  one  of  two  possible 
tasks.  It  either  transforms  a  iJDM-based  database  definition 
to  an  egulvalent  database  definition  based  on  the  <ernel 
data  model  (KDK);  or,  when  the  user  specifies  that  a  UDL 
transaction  is  to  be  executed,  it  translates  the  UDL 
transaction  into  an  egulvalent  transaction  in  the  Kernel 
data  language  (KDL), 

The  first  tasK  is  performed  in  the  following  way. 
The  KMS  forwards  the  KDM  data  definition  to  the  Kernel 
controller  (KC),  The  KC  then  sends  the  KDM  database 
definition  to  the  Kernel  database  system  (KDS),  When  the 
KDS  Is  finished  with  processing  the  KDM  database  definition, 
it  informs  the  KC,  The  KC  then  notifies  the  user,  via  the 
LIL,  that  the  database  definition   has   been   processed   and 
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that  the  loading  of  the  database  records  ^av  begin.  The 
second  tas»c  is  performed  In  a  similar  fashion.  The  KMS 
sends  the  transactions  to  the  KC  which  in  turn,  sends  the 
transactions  to  the  KDS  for  execution.  Once  the  execution 
is  comolete,  the  kds  sends  the  results  in  the  KDM  form  bacK 
to  the  KC,  The  KC  routes  the  results  to  the  Kernel 
formattina  system  (KFS).  The  KFS  reformats  the  results  from 
the  KDM  form  to  the  UOM  form.  The  KFs  then  displays  tne 
results  in  the  correct  UDM  form  via  the  LIL. 


^udlY 


UDM 

UDL 

LIL 

KMS 

KC 

KFS 

KDM 

KDL 

KDS 


User  Data  Model 
User  Data  Language 
Language  Interface  Layer 
Kernel  Mapping  System 
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Kernel  Formatting  System 
Kernel  Data  Model 
Kernel  Data  Language 
Kernel  Database  Svstem 


Figure  It  The  Multi-Lingual  Database  System  (mlps). 

The  four  modules,   LIL,   KMS,   KC,   and  KFS,   are 
collectively   icnown   as   the  laaouaoft  iattciftce,   four 
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Interfaces  with  similar  modules  are  required  for  the  four 
Interfacing  user  models  and  languages  Cl.et»  relational/SOL, 
hlerarchlcal/DL/l,  network/CODASYL-DML,  and  entlty- 
relatlonshlp/Daplex)  of  the  mlds, 

2.  Ibt  Multi-aacjcead  OAt«bafia  S^staa 

The  multl-bacicend  database  system  (MBhS)  was 
designed  to  overcome  the  performance  problems  and  upgrade 
problems  associated  with  the  traditional  approach  to 
database  system  design.  This  goal  was  realized  through  the 
utilization  of  multiple  bacicends  connected  In  a  parallel 
fashion.  The  bacicends  have  identical  hardware,  replicated 
software,  and  their  oun  disk  systems.  In  the  multl-backend 
configuration,  there  Is  a  backend  controller,  whlcn  is 
responsible  for  supervising  the  execution  of  database 
transactions  and  for  Interfacing  with  the  nosts  and  users. 
The  backends  perform  the  database  operations  with  the 
database  stored  on  the  disk  system  of  the  backends.  The 
controller  and  backends  are  connected  by  a  communications 
bus.  Users  access  the  system  through  either  the  hosts  or 
the  controller  directly  (see  Figure  2), 

Performance  gains  are  realized  by  increasing  the 
number  of  backends.  If  the  size  of  the  database  and  the 
size  of  the  responses  to  the  transactions  remain  constant, 
then  MBDS  produces  a  reciprocal  decrease  in  the  response 
times  for  the  user  transactions  when  the  number  of  backends 
is  increased.  On  the  other  hand,  if  the  number  of  backends 
is  increased  proportionally  with  the   increase   in   database 
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size  and  transaction  responses^  then  the  MBOS  produces 
Invariant  response  tlnnes  for  the  same  transactions.  For  a 
more  detailed  discussion  of  mbds  the  reader  Is  referred  to 
[Refs.  2  and  31, 


Backend  Store  1 


Communications 
Bus 


Backend  Store  2 


Backend  Store  M 


Figure  2i  The  Multl-backend  Database  System  (mbDS), 

In  this  thesis,  we  Investigate  the  design  of  a 
network  (CODASYL)  Interface  for  the  mLdS,  Banerjee  fRef,  4), 
provided  an  Initial  design  for  such  an  interface,  we  are 
extending  his  work  and  adapting  It  to  support  the 
requirements  of  the  mlos.  In  particular,  we  present  a 
specification  for  the  kernel  mapping  system  (KMS)  that  will 
be  used  In   the   network   Interface,    we   also   orovlde   an 
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Implementation  strateay  for  the  kernel  controller  (kc).  The 
other  two  modules,  the  LIL  and  the  KFS  are  nearly  the  same 
In  structure  as  those  already  Implemented  for  the  DL/I  and 
SQL  Interfaces,  and  thus,  they  will  not  be  discussed  In 
detail  In  this  thesis.  The  reader  Is  referred  to  [Refs,  5 
and  6]  for  further  details  on  the  design  of  these  modules. 

Throughout  this  thesis,  we  win  make  extensive  use 
of  the  Suppllers-and-Parts  samole  database  used  by  Date 
tRef,  71  for  Illustration  of  our  work.  The  data  structure 
diagram  for  this  network  Is  shown  in  Figure  3,  There  are 
supplier  records  (S),  parts  records  (H),  and  shipments  (SP) 
records.  The  sets  of  the  database  are  suopllers-shipments 
(S-SP)  and  parts-shipments  (P-SP), 


I    supDllers    I 


x.. 


(  S-SP  ) 


I 


...z 

(  P-SP  ) 


parts 


^.....-h. ...... ..4. 

I    Shipments    I 

Figure  3:  Data  Structure  Diagram  of  the  Saif^ple 
Suppllers-and-Parts  Database, 


In  Chapter  2,  we  provide  a  description  of  both  the 
network  CC3DASYL)  data  model  and  the  attribute-based  model, 
as  well  as,  their  associated  data  languages.  In  Chapter  3, 
a   methodology  for  maoplng  a  network  (CODASYL)  database  Into 
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an  attribute-based  database  Is  presented,  Chaoter  4  is 
dedicated  to  explaining  the  data  manipulation  language 
translations.  And,  In  Chapter  5,  we  Provide  Implementation 
condlderatlons  for  both  the  kmS  and  the  KC,  Finally,  In 
Chapter  6,  we  make  our  conclusions  about  the  proposed 
design. 
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II.   ZU£  OAZA  I&QOELS 

The  choice  of  a  kernel  data  model  and  a  corresponding 
kernel  data  language  is  of  vital  importance  In  developing  a 
multi-lingual  database  system.  The  kernel  data  model  and 
the  kernel  data  language  must  be  capable  of  supporting  all 
the  necessary  data  model  transformations  and  data  language 
translations  reguired  by  the  mlds  language  interfaces. 

It  is  our  intention  in  this  chapter  to  provide  a  summary 
description  of  the  data  models  related  to  the  network 
(CODASYL)  interface,  namely  the  CODASYL  data  model  and  the 
attribute-based  data  model,  A  conceptual  view  of  both 
models  will  be  presented  along  with  a  brief  discussion  of 
the  data  manipulation  languages  associated  with  each  model, 

A,   THE  CODASYL  DATA  MODEL 

In  general,  the  network  (CODASYL)  data  model  Is  based  on 
the  concept  of  directed  graphs.  The  nodes  of  the  graphs 
usually  represent  entity  types  which  are  described  by 
records,  while  the  arcs  of  the  graphs  correspond  to 
relationship  types  that  are  represented  as  connections 
between  records.  The  CODASYL  (Conference  on  Data  System 
Languages)  data  model  is  referred  to  by  Tsichritzis  and 
Lochovsky  [Ref,  8:pp,  119-132]  as  the  most  comprehensive 
specification  of  a  network  data  model  that  exists.  Thus,  the 
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reason  for  choosing  the  CODASYL  iata  model  and  Its  data 
manipulation  language  for  the  network  interface  of  the  MLDS, 
1.  k   CaocAQtuAl  ^Ltu   o£  tbA  Modal 

CODASYL  databases  are  networks  of  record  typ^s  and 
set  types,  where  records  and  sets  are  the  entitles  which 
describe  the  databases.  A  record  type  in  a  CODASYL  database 
is  defined  in  [Ref,  43  as  a  collection  of  hierarchically 
related  data  item  names  or  field  names.  These  field  names 
are  specified  in  a  schema  declaration  (template)  for  that 
record  type,  A  sacofid  is  any  occurrence  of  a  record  type  and 
has  specific  values  assigned  to  the  data  items  named  in  the 
schema  declarations.  This  implies  that  a  record  type  is 
simply  a  generic  name  for  all  of  the  records  that  are 
described  by  the  same  template. 

Set  types  in  a  CODASYL  database  indicate 
relationshlDS  between  record  types.  They  consist  of  a 
single  record  type  called  the  0ttAft£  record  type,  and  one  or 
more  record  types  called  the  fflasbfts  record  types.  Thus,  a 
set  type  expresses  explicit  associations  between  different 
record  types  in  the  database.  This  characteristic  makes  it 
possible  for  a  designer  to  model  a  large  variety  of  real 
world  database  management  problems  involving  diverse  record 
types.  Of  special  importance  here  is  the  fact  that  the 
owner  record  type  of  a  set  type  is  prohiolted  from  being  a 
member  of  the  same  set  tyoe. 

Set  types  have  occurrences  just  as  record  types  do, 
Each  occurrence  of  a  set  type  has  one  occurrence  of  the 

20 


owner  record  type  and  zero  or  more  occurrences  of  each  of 
Its  member  record  types.  The  prohibition  here  Is  that  a 
record  occurrence  cannot  be  oresent  In  two  different 
occurrences  of  the  same  set  type.  This  qualification 
emphasizes  the  pairwlse  dlsjolntness  of  set  occurrences  of  a 
given  set  type.  Figure  4  gives  an  example  of  a  set 
occurrence  for  the  set  type  S-SP  of  our  sample  database. 

As  can  be  seen  from  the  example,  the  CODASYL  data 
model  makes  the  design  of  a  database  quite  simple.  However, 
keeping  track  of  all  of  the  reiatlonshlos  can  be 
considerably  Involved,  Thus,  one  of  our  primary  concerns  In 
the  design  of  a  CODASYL  language  Interface  for  the  mlds  is 
to  preserve  these  relationships  without  the  complexity. 


S  (an  owner  record  occurrence) 
f. ••.....•..-•••. ••••••••-•»■ 

i  S2  I  Jones  I  10  I  Paris  I 

(a  set  occurrence) 
(S-SP) 

(two  member  record  occurrences) 
SP  SP 

4.. ....••••••. »»t    ♦--•.--—••---«-.+ 

i  S2  I  PI  I  300  i     I  S2  I  P2  I  400  | 


Figure  4i  A  CODASYL  Set  occurrence, 

2.  X&A  DfttA  MaaloulAtloa  Lafiouaot  (CQQASXL"&ttL) 

CQDASYL«DMI>  is  a  procedural  data  language.  The  user 
of  a  CODASYL  database  writes  his  programs  in  a  general 
purpose  language  that  hosts  the  CODASYL-DML,   In  general, 
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most  operations  in  a  CODASYL  database  are  carried  out  by 
"navlqatlng"  through  set  occurrences.  The  starting  oolnt 
for  this  navigation  Is  usually  the  current  record  of  the  run 
unit.  The  cuQ  u&it  Is  the  application  program  (transaction) 
belno  executed,  A  full  explanation  of  currency  will  be 
provided  later  In  the  thesis.  Other  Pml  operations  can  be 
based  on  the  current  record  occurrence  of  a  set  type  or 
record  type. 

CODASYL-DML  has  several  primary  operations  which 
support  the  primary  database  operations  of  retrieval* 
insertion,  deletion,  and  modification  (uodatlng  existing 
records).  Different  implementations  provide  varying 
collections  of  these  operations,  but  we  will  concentrate  our 
discussion  on  the  basic  ones. 

The  cornerstone  of  the  CODAsYL-Dml  Is  the  fin^D 
statement.  This  statement  is  used  to  establish  the  currency 
of  the  run  unit,  and  optionally  used  to  establish  the 
currency  of  the  set  type  and  the  record  type.  The  general 
format  of  the  FIND  statement  is 


FIND  record-selection-expression  [ 


]. 


where  the  square  brackets  contain  optional  expressions  for 
the  suppression  of  updates  to  the  currency  indicatorst  In 
other  words,  we  may  suppress  the  updating  of  the  currency 
for  a  record  type,  a  set  type,  or  both.  The  record- 
selection-expression  has   several  different   forms   each 
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designed  to  access  a  particular  record  In  three  different 
ways,  either  out-of-the-blue  without  reference  to  a 
previously  accessed  record;  relative  to  a  previously 
accessed  record;  or  by  repetition.  The  other  DWL.  statements 
are  somewhat  less  extravaaant. 

The  GET  statement  In  COf)ASYL-DML  complements  the 
FIND  Statement,  Once  a  record  Is  found,  the  GET  statement 
Places  the  record  In  the  transaction's  woriclng  area  for 
access  by  the  transaction.  There  are  two  basic  formats  for 
the  GLT  statement.  They  Include  GET  record. type,  which 
gives  the  transaction  access  to  the  entire  record,  and  GET 
Items  IN  record.type,  which  gives  access  to  only  requested 
data  Items  in  the  record  type. 

The  jSTORE  statement  is  used  to  Place  a  new  record 
occurrence  into  the  database.  The  programmer  must  build  up 
an  Image  of  the  record  prior  to  the  STORE  request  using 
assignment  statements  which  are  a  part  of  the  host  language 
in  which  the  CODASYL-DML  is  embedded.  Once  the  record  image 
has  been  created,  then  the  proper  set  occurrence  for  the 
record  must  be  selected  by  the  database  management  system. 

The  set  occurrence  in  which  the  new  record  is  stored 
is  determined  by  the  SET  SELECTION  clause  specified  in  the 
schema  definition  for  the  object  database.  The  three 
options  available  are:  BY  APPLICATION,  which  means  that  the 
application  program  (transaction)  is  responsible  for 
selecting  the  correct  occurrence;  by  value,  which  means  the 
system  selects  the  proper   occurrence   based   on   data   item 
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values  specific  to  the  owner  of  the  set  occurrence  deslrei; 
and,  BY  STRUCTURAL,  which  means  that  tne  system  selects  an 
occurrence  by  locating  the  owner  record  with  a  specific  Item 
value  equal  to  the  value  of  that  same  item  In  the  record 
being  stored.  The  restriction  on  tne  last  two  options  Is 
that  the  data  items  being  used  must  nave  been  specified  with 
DUPLICATES  NOT  ALLOWED  In  the  schema  definition.  A  detailed 
discussion  of  syntax  for  the  CODASYL-DmL  Is  presented  later 
In  the  thesis. 

If  the  user  transaction  desires  to  manually  Insert 
records  Into  the  database,  two  requirements  exist.  First, 
the  schema  definition  must  Include  the  INSERTION  is  MANUAL 
clause  in  the  set  desclptlon  for  this  particular  member 
record.  Then  the  connect  statement  is  used,  instead  of  the 
STORE  statement,  for  insertion  of  the  record  into  the 
database.  The  record  to  be  Inserted  Is  the  current  record 
of  the  run  unit.  The  set  occurrence  in  which  the  record  is 
Inserted  is  determined  in  the  same  way  as  the  STORE 
statement. 

There  is  also  a  statement  In  the  CODASYL-Dml  which 
performs  the  opposite  operation,  namely,  the  manual  removal 
of  a  record  occurrence  from  a  set.  The  disconnect  statement 
performs  this  operation.  It  disconnects  the  current  record 
of  the  run  unit  from  the  occurrence  o£  the  specified  set 
that  contains  the  record.  The  record  occurrence  still 
resides  in  the  database,  but  It  is  no  longer  a  member  of  the 
specified   set.   There  Is  a  qualification  involved  with  this 
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statement,  however.  The  record  to  be  disconnected  must  have 
a  RETENTION  clause  of  optional  In  the  memDer  desciPtlon  for 
the  set  type  definition  in  the  schema. 

In  order  to  delete  records  from  a  CODASYL  database, 
the  ERASE  statement  is  used.  There  are  four  basic  options 
to  this  statement;  however,  two  of  them  are  very  complex  and 
marginally  useful,  so  they  will  not  be  discussed  in  this 
thesis.  The  simplest  of  the  two  we  will  deal  with  is  the 
ERASE  without  the  ALL  ODtion,  This  statement  causes  the 
current  record  of  the  run  unit  to  be  deleted  from  the 
database  if,  and  only  If,  it  is  aot  the  owner  of  a  non-empty 
set.  If  it  is  the  owner  of  a  non-empty  set,  the  erase 
fails. 

The  ERASE  ALL  option  is  a  little  less  useful 
according  to  Oiie  CRef.  9],  This  statement  causes  the 
current  record  of  the  run  unit  to  be  deleted  whether  or  not 
it  is  the  owner  of  a  non-empty  set.  Additionally,  this 
option  causes  each  member  record  of  the  set  to  be  deleted, 
and  if  they  too  are  owners  of  non-empty  sets,  their  members 
are  deleted.  This  action  continues  all  the  way  down  the 
hierarchy.  As  one  can  see,  an  entire  database  could  be 
destroyed  If  the  user  is  not  careful  when  using  this  option. 

The  final  statement  to  be  covered  in  this  thesis  Is 
the  MODIFY  statement.  It  is  used  to  modify  values  of  data 
items  in  a  record  occurrence.  This  includes  modifying  all 
data  items  or  any  subset  of  the  data  items  in  the  record 
type.   It  may  also  be  used  to  change   the   membership   of   a 
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record  occurrence  £ro"i  one  set  occurrence  to  another,  as 
long  as,  they  are  of  the  same  set  type.  Thus,  we  have  our 
basic  wor»clng  set  of  DML  statements, 

B.   THE  ATTRIBUTE-BASED  DATA  MODEL 

The  attribute-based  data  model  was  originally  described 
by  Hsiao  CRef,  10],  It  is  a  very  simple  but  powerful  data 
model  capable  of  representing  many  other  data  models  without 
loss  of  Information,  It  is  this  simplicity  and  universality 
that  maKes  the  attribute-based  model  the  ideal  choice  as  the 
kernel  data  model  for  the  mldS,  and  the  attribute-based  data 
language  (ABDL)  as  the  kernel  language  for  the  system. 

The  attribute-based  data  model  Is  based  on  the 
notions  of  attributes,  and  values  for  these  attributes.  An 
attribute  and  its  associated  value  is  therefore  referred  to 
as  an  AtlcXbUtft-Jiaiuft  Dal£  or  l^ftVMoSd.  These  attribute- 
value  pairs  are  formed  from  a  Cartesian  product  of  the 
attribute  names  and  the  domains  of  the  values  for  the 
attributes.  Using  this  approach,  any  logical  concept  can  be 
represented  by  the  attribute-based  model. 

A  £ftCO£d  9  In  the  attribute-based  model  represents  a 
logical  concept.  In  order  to  specify  the  concept 
thoroughly,  keywords  must  be  formed,  A  record  then,  is 
simply  a  concatenation  of  the  resultant  keywords,  such  that 
no  two  keywords  in  the  record  have  the  same  attribute. 
Additionally,   the  model  allows  for  the  inclusion  of  textual 
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information,  called  the  cecofid  haiu  t  In  the  form  of  a, 
possibly  empty,  string  of  characters  describing  the  record 
or  concept.  The  record  body  Is  not  used  for  search 
purposes.    Figure   5  gives  the  format  of  an  attrloute-based 


record. 


COttrlbutel ,  valuei>,  .,,  , 
<attrlbuten,valuen>, 
{  text  >) 


Figure  5i  An  Attribute-Based  Record 

The  angled  brackets,  <,>,  are  used  to  enclose  a  keyword 
where  the  attribute  Is  first  followed  by  a  comma  and  then 
the  value  of  the  attribute.  The  record  body  Is  then  set 
apart  by  curly  brackets,  <,},  Tne  record  itself  is 
identified  by  enclosure  within  parentheses.  As  can  be  seen 
from  the  above,  this  is  quite  a  simple  way  of  representing 
information. 

In  order  to  access  the  database,  the  attrlbute»based 
model  employs  an  entity  called  predicates.  A  keyword 
predicate,  or  simply  astidicatA  ,  is  a  triple  of  the  form 
(attribute,  relational  operator,  value).  These  predicates 
are  then  combined  in  disjunctive  normal  form  to  produce  a 
auACii  of  the  database,  in  order  to  satisfy  a  predicate,  the 
attribute  of  a  keyword  in  a  record  must  be  identical  to  the 
attribute  in  the  predicate.  Also,  the  relation  specified  by 
the  relational  operator  of  the  predicate  must  hold  between 
the  value  of  the  predicate,  and  the  value  of  the  keyword,   A 
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record  satisfies  a  query  If  all  predicates  of  the  query  are 
satisfied  by  certain  keywords  of  the  record,  A  query  of  two 
predicates 

(TYPE  =  S)  and  (SNO  a  S4) 

would  be  satisfied  by  any  record  of  TYPE  S  (supplier  type) 
Whose  SNO   (supplier  number)   Is  S4,  and  it  would  have  the 

form, 


(<attrlbutel,vauel>,  ,,,  ,<TYPE,S>,  .,•  , 
<SN0,S4>,  ,,,  ,<attrlbuten,valuen>r <text> ) , 


The  ABDL  as  defined  by  Banerjee,  Hsiao,  and  Kerr 
CRef,  11]  was  originally  developed  for  use  with  the  Database 
Computer  (DBC),  This  language  Is  the  icernei  language  used 
In  the  MLDS,  The  ABDL  supports  the  five  primary  database 
operations,  INSERT,  DELETE,  UPDATE,  RETRIEVE,  and  RETRIEVE* 
COMMON,  Those  of  use  to  us  In  this  portion  of  the  mlds  wortc 
nowever,  are  INSERT,  DELETE,  UPDATE,  and  RETRIEVE,  A  user 
o£  this  language  Issues  either  a  request  or  a  transaction, 
A  £gauAtt  in  the  ABDL  consists  of  a  primary  operation  with  a 
qualification.  The  auali£ica£io&  specifies  the  portion  of 
the  database  that  is  to  be  operated  on.  When  two  or  more 
requests  are  grouped  together  and  executed  sequentially,  we 
have  a  tcaaaactiaa  in  the  ABDL,  There  are  four  types  of 
requests,   corresponding   to  the  four  primary  database 
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operations  listed  above.  They  are  referred  to  by  the 
same  names. 

Records  are  Inserted  Into  the  database  with  an 
INSERT  request.  The  qualification  for  this  request  Is  a 
list  of  iceywords  and  a  record  body.  Records  are  removed 
from  the  database  by  a  DELETE  request.  The  qualification 
for  this  request  Is  a  query, 

When  records  In  the  database  are  to  be  modified,  the 
UPDATE  request  is  utilized.  There  are  two  parts  to  the 
qualification  for  this  request.  They  are  the  query  and 
modifier.  The  query  specifies  the  records  to  be  modified 
»»hile  the  modifier  specifies  how  tne  records  are  to  oe 
modified. 

The  final  request  to  be  mentioned  here  is  tne 
RETRIEVE  request.  As  its  name  implies,  it  retrieves  records 
from  the  database.  The  qualification  for  this  request 
consists  of  a  query,  a  target-list,  and  an  optional  by- 
clausct  The  query  specifies  the  records  to  be  retrieved. 
The  target-list  contains  the  output  attributes  whose  values 
are  required  by  the  request,  or  It  may  contain  an  aggregate 
operation,  i,e,,  AVG,  COUNT,  SUM,  mIn,  max,  on  one  or  more 
output  attribute  values.  The  by-clause  is  optional  and  is 
used  to  group  records  when  an  aggregate  operation  is 
specified. 

As  Indicated,  ABDL  consists  of  some  very  simple 
database  operations.  These  operations,  nevertheless,  are 
capable   of   supporting    complex    and    comprehensive 
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transactions.  Thus,  abdl  meets  the  requirement  of  capturlnq 
all  of  the  orimary  operations  of  a  database  system,  and  Is 
quite  useful  for  our  purooses.  Figure  6  snows  examples  of 
the  four  primary  ABDL  requests, 

INSERT(<rYPF,SP>,<SNO,S2>,<PNO,Pl>,<QTy,300>, (sample>) 
DELFTECCTYPE  a  S)  and  (SNO  s  S4)) 

UPDATECCTYPE  s  SP)  and  (PNO  a  P1))(QTY  a  QTY  t  100) 
RETRIEVFCCTYPE  =  P)  and  (PNAME  a  Nut)) 

Flqure  6:  Sample  ABDL  Requests, 
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III.   MASeittC  £l£ZMQ&K  CCQQASXL)  DAI&  10  AZI&XfiUie-aAS£&  QklL 

Using  a  modification  of  a  procedure  originally  outlined 
by  Banerjee  tRef,  43,  the  transformation  of  network  data 
Into  attribute-based  data  becomes  a  relatively  simple  tasic. 
The  data  must  be  transformed  Into  records  wnlch  consist  of  a 
set  of  varlable-lenqth  attrlbute»value  pairs  and  a  record 
body.  The  attribute-value  pairs  may  represent  the  type, 
quantity,  or  characteristic  of  the  value,  and  the  record 
body  is  as  described  in  the  previous  Chapter.  Additionally, 
all  attributes  in  the  attribute-based  records  are  distinct, 
for  logical  reasons. 

The  key  aspect  of  the  mappij^g_prjocess  is  the  retention 
of  the  cnDASYL  notions  of  records  and  sets  (the  linkages 


among  records),   we  emphasize  that  the  CODASYL  notions   of 


records  and  sets  are  &ot  the  same  as  the  attribute-based 
notions  of  records  and  sets.  ThuSf  the  mapping  algorithm 
presented  herein  uses  attribute-based  constructs  (or 
notions)  to  implement  the  CODASYL  notions.  In  the  following 
sections*  we  present  the  various  entitles  which  must  be 
mapoed,  their  corresponding  attribute-based  equivalent,  and 
an  example  of  the  mapping  process  using  our  sample  database. 
It  Should  be  clear  after  this  description,  that  the  CODASXL 
notions  of  records  and  their  relationships  are  indeed 
preserved  in  the  attribute-based  system. 
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A,   THE  REPRESENTATION  OF  A  CODASYL  RECORD 

A  CODASYL  record  type  Is  structured  as  a  hierarchical 
configuration  of  data  items  such  as  depicted  in  Figure  7(a), 
where  Rl  is  the  record  name,  and  A,  B,  C,  D,  E,  and  F 
represent  data  item  names.  Figure  7(b)  snows  an  occurrence 
of  record  Rl,  Notice  that  only  the  values  of  the  data  Items 
are  present  in  the  CODASYL  record,  in  the  attribute-based 
system,  both  the  data-item-name  and  its  value  are  stored  in 
the  record. 


Record  Rl 


01  A 
01  B 

02  C 

02  D 
03  E 

02  A 
01  F 


Record  Rl 

aOl.value 
bOl. value 
c02»value 
d02.value 
e03.ivalue 
a02»value 
f Ol.vBlue 


(a)  (b) 

Figure  7:  Hierarchical  Structure  of  a  CODASYL  Record, 

Thus,  in  order  to  capture  the  CODASYL  information,  Keywords 
must  be  created  for  each  of  the  elementary  data  items 
Included  In  the  CODASYL  record.  These  data-item  iceywords 
should  be  of  the  form 

<  data.item.name,data.ltem«value  > 

Where  the  data-item-name  is  qualified  by  data-item-names  at 
a  higher  level  if  It  is  not  unique.  Figure  8  shows  the  data 
item   representation   for   the  CODASYL  record  of  Figure  7, 
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(.,,,<  A, a. value  >,<  B,b.value  >, 

<  C,c»value  >,<  D, devalue  >, 

<  E,e«value  >,<  B,A,b,a«v»iue  >, 

<  F,f. value  >,...) 


Figure  8j  Attribute-Based  Representation  of 
CODASYL  Data  Items, 


The  dots  at  the  beqlnnlng  of  the  record  and  the  dots  at  the 
end  of  the  record  indicate  that  there  are  additional 
keywords  generated  for  the  record  in  order  to  preserve  the 
CODASYL  record  Information,  These  additional  keywords  are 
explained  as  follows* 

Lach  record  occurrence  In  a  CODASYL  database  must  also 
belong  to  a  particular  type.  This  implies  that  a  iceyword 
Indicating  record  type  must  also  be  included  in  the 
attribute*based  record.   Its  format  is 

<  TYPE,record»type  > 

where  TYPE  is  a  literal. 

Finally,  each  record  occurrence  of  a  CODASYL  database 


has  a  database  key  (or  address)  generated  for  it.  Thus, 
there  is  a  requirement  for  representation  of  this  value  as 
well  in  the  attribute-based  record.  The  following  form  is 
used  for  this  Iceyword,  where  dbkey  is  a  literal. 


</ DBKEXr<^atabase.lcey  > 
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So,  in  representing  record  Information,  we  have  the  need 
for  three  mandatory  keyword  types,  namely,  data.ltem.name, 
with  or  without  qualification,  TYPE,  and  dbkey, 

B.   THE  REPRESENTATION  OF  CODASYL  SETS 

In  order  for  the  attrlPute-based  record  to  be  complete, 
It  must  also  Include  information  related  to  COOASYL  set 
membership,  and  set  ordering.  Since  occurrences  of  set 
types  are  pairwise  disjoint,  then  each  member  record 
occurrence  belonging  to  a  set  occurrence  is  also  identified 
t»V  its  owner  record  occurrence.  This  means  that  we  can 
express  set  membership  by  inclusion  of  the  keyword 

<  MEMBER.set»type,owner«databa6e.tcey  > 

for  each  set  occurrence  in  which  the  record  is  a  member. 


Finally,  the  logical  position  of   a  record  occurrence^ 
within  a  set  occurrence  is  often  useful.   Thus,  ordering  of 


member   record  occurrences   within  a  set  occurrence   is 


expressed  by  inclusion  of  the  keyword 


<  POSITION, set-type, sequence.number  > 


in  the  attribute-based  record  for  each  set  in  which  the 


record  is  a  member  record. 

Therefore,  in  representino  set  information,  we  have  the 


need  for  two  keyword  types,  those  representing  member 
records,  and  those  representing  member-record  positions 
within  sets. 
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C,   A  COMPLETE  DATA-MAPPING  EXAMPLE 

As  previously  mentioned,  by  utilizing  tne  ^bove 
transformation  scheme,  we  can  talce  an  existing  CODASYL 
database  and  transform  it  into  an  attribute-based  database 
without  any  loss  of  information  related  to  tne  CODASYL 
records  and  sets  (i.e.,  record  relationships).  The 
transformation  should  therefore  result  In  records  of  the 
form  shown  in  Figure  9, 


(<   TYPE, record. type   >,<   DBKEY,database.lcey   >, 
<   data.item.namel  ,data»ltem.ivaluel    >, 


<  data. item. namen^data-item.valuen  >, 

<  MEMBER, set. typel , owner. database.keyl  >, 


<  MEMBER, set. typep, owner. database. Iceyp  >, 

<  POSITION, set. typel , sequence. number  >, 

• 
* 

<  POSITION, set. typep,sequence.nuffiber  > 

<  textual  information  >) 

Figure  9:  An  Example  of  a  Transformed 
CODASYL  Record, 


35 


SCHEMA  NAME  IS  SUPPLIERS. AND. PARTS, 
RECORD  NAME  IS  S; 

DUPLICATES  ARE  NOT  ALLOWED  FOR  SNO, 


SNO 
SNAME 
STATUS 
CITY 


; 


TYPE  IS  CHARACTER  5, 

TYPE  IS  CHARACTER  20, 

TYPE  IS  FIXED  20, 

TYPE  IS  CHARACTER  15, 


PNO, 


RECORD  NAME  IS  P; 

DUPLICATES  ARE  NOT  ALLOWED  FOR  pNO, 

PNO     ;  TYPE  IS  CHARACTER  6, 

PNAME   ;  TYPE  IS  CHARACTER  20, 

COLOR   ;  TYPE  IS  CHARACTER  6, 
•HEIGHT  ;  TYPE  IS  FIXED  4, 

CITY    ;  TYPE  IS  CHARACTER  lb, 

RECORD  NAME  IS  SP; 

DUPLICATES  ARE  NOT  ALLOWED  FOR  SNO, 
SNO     ;  TYPE  IS  CHARACTER  5, 
PNO     ;  TYPE  IS  CHARACTER  6. 
OTY     ;  TYPE  IS  FIXED  5, 


SET  NAME  IS  S.SP; 
OWNER  IS  s; 

ORDER  15  SORTED  BY 

DUPLICATES  ARE  NOT 
MEMBER  IS  SP; 

INSERTION  IS  AUTOMATIC 

RETENTION  IS  FIXED; 

KEY  IS  ASCENDING  PNO  IN  SP; 

SET  SELECTION  IS  RY  VALUE  OF  SNO  IN  S, 


DEFINED  KEYS 
ALLOWED, 


DEFINED  KEYS 
ALLOWED, 


SET  NAME  IS  P.SP; 
OWNER  IS  P; 

ORDER  IS  SORTED  BY 

DUPLICATES  ARE  NOT 
MEMBER  IS  SP; 

INSERTION  IS  AUTOMATIC 

RETENTION  IS  FIXED; 

KEY  IS  ASCENDING  SNO  IN  SP; 

SET  SELECTION  IS  BY  VALUE  OF  PNO  IN  p. 


Figure  lOi 


Schema  for 
Database, 


the  SuppIlers-and-Parts 


In  order  to  demonstrate  the  transformation  process 
further.  Figure  10  above  provides  the  schema  definition  for 
our  samole  Suppiiers-and-Parts  database.   usinq  this  schema 
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definition,  the  CODASYL  record  occurrences  of  Figure  11   are 
transformed  into  the  attrlbute-hased  records  of  Figure  12, 


S 

^•.•.•••. ...••«..•.• ••••..^ 

I  S2  I  Jones  I  10  I  Paris  I 

+-•--------•••-"-•■••----•-•♦• 

P 

I  PI  I  Nut  I  Red  I  12  I  London  I 

SP 

I  S2  I  PI  I  300  i 

+•-------•----•-♦ 

FlQure  11:  Sample  Record  Occurrences  from  the 
Suppliers-and-Parts  Database, 


(<TYPE,S>,<DBKEy,l>,^ 
<SN0,S2>,<5NAWE,Jones>, 
<STATUS,lO>,<CITy,Parl8>, 

<  Sample  supplier  record  >) 

(<TYPE,P>,<DBKEy,2>,^ 
<PNO,Pl>,<PNAME,Nut>r 
<COLOR,Red>,< WEIGHT, 12>, 
<CITY,London>, 

<  Sample  parts  record  >) 


(<TYPE,SP>,<DBKEy,3>, 
<SN0,S2>,<PN0,P1>, 

<'3Ty,300>,  - ^ 

<MEMBCR,S.SP,1>V 

<MEMBER,P.SP,2>, 

\  <P0SITI0N,S»SP,1>, 

^  <P0SITI0N,P.SP,1>, 

<  Sample  SP  record 

belongs  to  two 


3 


where  the 
different 


record 
sets  >) 


Figure  12j  Attribute-Based  equivalent  of  Record 
Occurrences  in  Figure  li. 
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IV.   ttAeeXttC  COQASXL-OttL  SZAXEiie&iZS  ZQ  LhUU   geOU£SZS 

Having  demonstrated  how  network  databases  can  be 
successfully  transformed  Into  attribute-based  databasesr  we 
are  now  ready  to  examine  the  mapping  of  networic  data 
manipulation  statements  Into  ABDL  requests.  As  mentioned  in 
Chapter  2,  the  CODASYL  data  manipulation  language  will  be 
used  for  the  mlds  network  Interface.  It  should  be  noted 
here  though,  that  only  a  subset  of  all  the  available  DML 
statements  will  be  used  in  the  mlds  network  interface. 
Specifically,  the  following  COdasyl  statements  will  be 
incorporatei  in  this  stage  of  the  project:  FIND,  GET,  STORE, 
CONNECT,  DISCONNECT,  ERASE,  and  MODIFY,  Of  these,  only  the 
useful  formats  were  considered  for  the  mlds.  It  should  be 
further  noted  that  the  syntax  for  these  various  statements 
was  derived  from  the  syntax  presented  by  Date,  Olle,  and  the 
original  CODASYL  report  [Refs,  7,  9,  and  12],  respectively. 

In  this  section  we  discuss  each  of  the  above  statements 
and  their  associated  mapping  process.  Prior  to  describing 
the  mapping,  however,  we  first  explain  the  notion  of 
currency  in  a  CODASYL  database,  and  introduce  the  data 
structures  that  are  necessary  to  carry  out  the  mapping 
process.  The  Appendix,  the  KMS  (Kernel  Mapping  System) 
specification,  gives  a  detailed   look  at  the  mapping  process 
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and  the  specific  algorithms  applied  to  accomplish  the 
language  translations, 

A,   THE  NOTION  OF  CURRENCY 

In  qeneral,  the  above  data  manipulation  statements  can 
be  grouped  into  two  categories^  data  retrieval  statements 
and  data  updating  statements.  However,  the  common  thread 
between  the  two  groups,  as  well  as,  tne  Individual 
functionality  of  each  statement,  depends  quite  heavily  on 
the  notion  of  cU£ceBCV  among  the  records  and  sets  of  the 
CODASYL  database. 

The  concept  of  currency  in  a  CODAsYL  database  can  be 
compared  to  the  well  known  concept  of  current  position  in  a 
file.  The  idea  here  is  that  for  each  application  program 
being  run  on  the  system,  a  table  of  "currency  indicators"  is 
maintained.  In  general,  the  currency  indicator  is  an  object 
whose  value  is  a  dAtabasft  l(*Vt  It  serves  as  a  "cursor** 
which  points  to  either  a  record  or  a  set  under  consideration 
by  the  application  program.  Database  iceys  are  values 
generated  by  the  database  management  system  that  uniquely 
Identify  each  individual  record  in  the  database. 

The  currency  indicator  table  for  a  given  application 
program  (or  run  unit)  identifies  the  record  occurrence  "most 
recently  accessed"  by  the  run  unit  for  each  of  the 
following:  each  type  of  record,  each  type  of  set,  "any  type" 
of  record,  and  each  type  of  realm  (Realm  is  a  CODASYL 
concept   that  will   not  be  considered  in  this  thesis.)  "Any 
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type"  of  record  refers  to  the  most  recently  accessed  record 
occurrence,  no  matter  what  Its  type  is.  This  record  is 
appropriately  called,  the  cu££A&t  fit  tUA  £Uq  UQit  ,  and  is 
the  most  Important  currency  of  all.  Additionally,  the 
cu£caat  o£  t&a  h&L  ty&A  nnay  be  either  an  owner  record  or  a 
member  record,  whichever  was  accessed  most  recently, 

B,   DATA  STRUCTURFS  NECESSARY  FOR  ACCURATE  TRANSLATION 

1,   Xbft  Cu£Cftac;(  lodlcAtAJ:  labia  (CXX) 

A  currency  Indicator  table  (CIT)  is  created  for  each 
application  program  that  is  run  using  the  MLDS  networtc 
interface.  These  tables  are  dynamic  in  nature.  They  are 
instantiated  upon  the  first  call  to  the  database  system,  and 
are  updated  as  subseauent  CODASYL-DML  calls  are  made  to  the 
database  system. 


CIT 

RUN. UNIT 

record.type 
database.Key 

record. type(i) 
database.key 

set.type(i) 

boolean  (is  record  an  owner  record) 

record.type 

database.lcey 

member. record. type 

owner.record.type 

owner.database.Key 

Figure  I3i   Information  Contained  in  the  CIT, 


The  CIT  contains  an  entry  for  the  current  of  run 
unit,  the  current  of  record.type  for  each  record. type  in  the 
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database,  and  th«  current  of  set-type  for  each  set.type  In 
the  database,  Each  entry  in  the  CIT  should  contain  at  least 
the  information  shown  In  Fiqure  13  as  sugqested  by  Meyer 
CRef,  13], 

2,  Zba  Saaufi&t  &u££ft£  (S&) 

When  mapping  the  CODASYL-DML  statements  to  abdl 
requests,  there  are  one-to-many  correspondences  between  tne 
two  types  of  statements.  Thus,  for  each  COOASYL-DML 
statement,  several  ABDL  requests  may  have  to  be  generated  to 
assemble  the  necessary  information  for  accurate  execution  of 
the  translated  codasyl-dml  statement.  In  other  words,  a 
series  of  abDL  requests  may  be  generated  for  each  CODASYL- 
DML»  statement.  Some  of  the  requests  are  initially 
incomplete,  however,  and  require  information  returned  by 
previous  RETRIEVE  requests  which  are  a  part  of  that 
statement's  translation.  This  Implies  the  need  for  storage 
of  Intermediate  information  for  the  requests. 

The  request  buffer  CRB)  acts  as  that  storaqe 
mechanism  for  information  returned  by  what  we  term, 
auxiliary  retrieve  requests  (ARR'S),  There  must  be  one  RB 
for  each  RETRIEVE  request  issued.  The  exact  role  that  each 
buffer  Plays  is  explained  in  the  next  section  of  this 
chapter.  In  general  though,  upon  successful  execution  of  an 
ARR,  all  record  occurrences  satisfying  the  request  are 
maintained  in  the  buffer.  This  information  is  then  used  for 
subsequent  request  execution. 
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C,   MAPPING  THE  FIND  STATEMENTS  TO  THE  ABDL  RETRIEVES 
The  general  format  of  the  CODASYL  FIND  statement  Is 

FIND  record.Belectlon-expresslon  t    J, 

while  the  general  format  of  the  A8DL  retrieve  is 

RETRIEVE  Query  Target-list  I  by  Attributes  ). 

As  previously  stated,  there  are  several  for-nats  for  the  FIND 
statement,  each  with  a  different  functionality.  Some  of 
these,  however,  are  thought  to  be  considerably  more  useful 
than  others,  so  we  only  concern  ourselves  with  the  ones  of 
most  value  in  the  mlds.  Before  proceeding,  tne  reader 
should  note  that  in  CODASYL  statements,  upoer-case  notation 
represents  literals,  lower-case  represents  user  supplied 
variable  names,  and  square  brackets  indicate  optional 
clauses,  we  now  examine  the  mapping  process  for  each  of  the 
CODASYL  statements  to  be  included  in  the  mldS  network 
interface, 

1.  ibft  exttO  AtfX  Stataaaat 

The  FIND  ANY  Statement  tells  the  database  system  to 
locate  any  record  of  type,  record.typel ,  whose  values  for 
iteml  through  itemn  match  those  in  that  record's  template  in 
the  user  work  area*  The  syntax  for  the  FIND  any  ist 


find  ANY  record.typel  USING  Iteml,  ,,,  , itemn 
IN  record, typel. 


To  perform  the  mapping  of  this  statement,  the  kernel  mapping 
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system  (KMS)  must  first  substitute  the  word  RETRIEVE  for  the 
words  FIND  ANY,  Then  the  kms  must  form  a  predicate,  fTYPE  = 
record. typel) ,  for  Inclusion  In  the  final  query.  The  next 
step  In  the  process  requires  the  kms  to  determine  the  values 
that  the  search  Is  to  be  based  ont  Ihese  values  are  found 
in  record.typel's  record  template. 

After  acquiring  these  values,  the  Kms  then  forms 
additional  predicates  for  the  data  Items  specified  In  the 
original  statement,  and  includes  these  predicates  In  the 
query.  Since  all  ot  the  necessary  information  is  available 
to  the  KMS  for  this  particular  CODASyL  statement,  there  is 
no  need  for  an  auxllllary  retrieve  request  (ARR),  However, 
an  R6  is  needed  to  store  the  retrieved  data  once  the  request 
has  been  executed. 

With  the  query  now  formed,  the  kms  creates  a 
target-list  to  complete  the  RETRIEVE  request.  The  target- 
list  consists  of  all  attributes  of  the  requested  record. 
Thus,  the  translated  CODASYL-DML  statement  Isi 


RETRIEVE  ((  TYPE 
Clteml 


record. typel)  and 
user.valuel)  and 

and 


(Itemn  b  user.valuen) ) 

(  all  attributes  )  i   by  DBKEY  ], 


This  request  Is  then  passed  to  the  KC  of  the  interface  for 
execution.  An  example  utllizlnq  our  sample  database  will 
help  to  illustrate  the  mechanics  of  the  mapping  process. 
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The  requirement  Is  to  find  any  Supplier  record,  S, 
where  that  supplier's  city  Is  'Cleveland',  The  Codasyl 
procedure  Ist 


MOVE  'Clevelanfl'  TO  CITY  IM  s 
FIND  ANY  S  USII^G  CITY  IN  S 


(Note;  The  move  statement  Is  an  assignment  statement  found 
In  the  host  COBOL  language,)  The  KMS  would  respond  to  this 
series  of  code  by  performing  the  following  actions: 


Step  1:  'Cleveland'  Is  placed  In  the  S   template   for   the 
attribute  CITY, 

Step  2:  A  RETRIFVE  request  Is  formed  as  suchi 

RETRIEVE  ((TYPE  a  S)  and 

(CITY  s  'Cleveland')) 
(SNO,  SNAME,  STATUS,  CITY) 
by  DBKEY 


Step  3!  The  KMS   passes   the  request   to  the  KG  for 
execution. 

This  operation  results  In  having  all   s   records   satisfying 

the   query   ((TYPE  a  S)  and  (CITY  a  'Cleveland'))  placed  In 

the  request  buffer  and  sorted  according  to  the  value  of   the 

database   l^eys.    Figure  14  shows  the  contents  of  Bufl  after 

the  RETRIEVE  Is  executed. 


I  I 

i  <S6, Mathews, 25, Cleveland>   I 

I  <S6, Jones, 30, Cleveland>     I 

I  I 

Figure  14:  Contents  of  Bufl  After  RETRIEVE, 
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upon  issuance  of  a  GET  statement  by  the  user,  the  first 
record  In  the  RB  Is  returned,  provided  the  RETRIEVE  has  been 
successful, 

2.   Z&a  SILO  CUS&EUZ  StatAAAfit 

The  FIND  CURRENT  statement  is  a  rather  simple  one  In 
that  no  direct  mapping  to  an  ABOL  request  Is  necessary. 
This  statement  Is  used  to  change  the  current  of  run  unit 
Indicator  from  Its  present  value  to  the  value  of  the 
database  icey  of  the  current  record  of  set-typel.  Thus,  the 
Interface  has  the  responsibility  of  updating  the  current  of 
run  unit  Indicator  (i.e.,  CIT, RUN. UNIT, type  <--  record. typel 
and  CIT, RUN. UNIT, dbkey  <—  dbkey  of  current  of  set. typel). 
The  syntax  for  this  statement  Isi 

FIND  CURRENT  record. typel  WITHIN  set.typel 

As  an  example  of  this  process,  suppose  we  desire  to 
start  a  search  at  the  current  SP  occurrence  in  set. type  s- 
SP,   The  CODASYL  Statement  would  bei 

FIND  CURRENT  SP  WITHIN  S-SP 

After  encountering  this  statement,  the  kms  passes  the  update 
information  on  to  the  KC  for  execution.  The  KC  then  updates 
the  currency  indicators  to  reflect  tne  changes.  The  current 
o£  run  unit  becomes  the  current  SP  record  occurrence  of  the 
current  S-SP  set  occurrence. 
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3.   Zbft  ZIUU   OU&LICAZE  ^IZUIU   Statasaot 

The  FIND  DUPLICATE  5taterT>ent  is  usei  for  sequential 
access  within  a  particular  set  occurrence,  it  locates  the 
first  record.typel  record  within  the  current  set.tyoel 
occurrence  whose  values  for  iteml  through  itemn  match  ttiose 
of  the  current  record  of  set.typel.  The  syntax  used  for 
this  statement  isi 


FIND  DUPLICATE  WITHIN  set.typel  USING 
iteml,  ,,,  ,itemn  IN  record^typel 


The  mapping  process  for  this  request  assumes  that 
the  records  being  requested  are  already  in  an  RB. 
Therefore,  no  RETRIFVE  request  is  generated  for  this 
statement.  Instead,  the  KMS  forwards  the  set  type,  record 
type,  and  the  data  item  nameCs),  on  which  the  search  is 
based,  to  the  KC.  The  KC  then  talces  this  information,  and 
locates  the  RB  containing  the  set.  It  then  compares  the 
specified  data  item  values  for  the  current  record  of  the  set 
type  to  each  of  the  other  member  records  until  the  first 
duplicate  record  within  the  set  is  found.  This  record  is 
made  available  for  return  to  the  user.  The  CIT  is  then 
updated  to  reflect  the  new  currency  status.  This  approach 
is  advantageous,  in  that,  all  of  the  records  for  a 
particular  set  occurrence  are  already  available  in  an  RB, 
eliminating  the  need  for  further  accesses  to  the  database  in 
the  event  of  subsequent  requests  for  duplicate  records,  such 
as  would  be  the  case  in  a  loop. 
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The  following  example  Illustrates  the  maoplng 
processi  Find  the  next  shipment  record  tor  supoller  SI  in 
*»hlch  the  quantity  snipped  is  100,  A  oosslble  COOASYL 
procedure  for  accomplishing  this  consists  of  the  following 
stateTients: 


MOVE  'Si'  TO  SNO  IN  S 

FIND  ANY  S  USING  SKO  IN  S 

MOVE  100  TO  QTY  IN  SP 

FIND  SP  WITHIN  S-SP  CURRENT  USING  QTY  IN  SP 

FIND  DUPLICATE  WITHIN  S-SP  USING  QIY  IN  SP 


The  effect  of  the  first  four  statements  Is  to  locate  the 
first  SP  occurrence  for  supplier  Si  that  has  a  OTY  of  100, 
The  next  statement  finds  the  next  SP  record  In  the  S-SP  set 
with  the  same  OTY,  namely,  100, 

The  Interface  would  respond  to   the   FIND   DUPLICATE 
request  as  follows: 


Step  li  Execution  of  the  first   four  statements   produces 
the  results  In  the  RB  of  Figure  15, 


step  2:  The  KC  then  gets  the  value  of  the  data  item, 
QTY,  by  going  to  the  RB  and  finding  the  current 
record  of  the  S-SP  set  using  the  record„type  and 
set.type  information  given. 


Step  3j  The  KC  now  locates  the  next  record  In  the  set  with 
QTY  »  too  and  maices  it  ready  for  return  to  the 
user. 
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<S1,P5,100> 
<S1,P6,100> 
<S1,P8,100> 
<S1,P10,100> 


Figure  l5j  Contents  of  bufl. 


I 
I 
I 
I 
I 
I 
■  ♦ 


4.   Ibft  £I^Q  EI&&Z  StateA«fi& 

The  FIND  FIRST  Statement  locates  the  first  member 
record  of  a  set  occurrence.  This  statement  has  several 
other  forms:  find  LAST,  find  next,  and  FIND  PRIOR,  Since 
they  are  all  mapped  in  exactly  the  same  way,  we  only 
describe  the  mapping  process  for  the  Find  FIRST,  The  syntax 
for  the  FIND  FIRST  isi 

FIND  FIRST  record. typel  within  set-typel 

Upon  encountering  the  FIND  FIRST,  the  KMS  must 
ensure  that  record, typel  is  a  member  record  type  of 
set.typel.  This  is  necessary^  since  this  particular  FIno  is 
based  on  the  currency  indicators,  and  the  current  of 
set.typel  may  be  an  owner  record,  as  noted  earlier  when 
discussing  currency  of  set  types.  Assuming  that  the  current 
record  of  set.typel  is  a  member  record,  the  KMS  then  forms  a 
RETRIEVE  request  that  will  retrieve  every  member  record  of 
the  current  set.typel  occurrence  into  its  RR,  The  Interface 
would  then  only  have  to  return  the  first  record  in  the  set 
in  order  to  satisfy  the  request.  If  the  statement  had  been 
FIND  LAST,   the   last  record  in  the   set  would  be  returned. 
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The  response  would  be  similar  for  the  FIND  next  and 
FIND  PRIOR  statements,  Assumlnq  that  the  set  occurrence  has 
already  been  retrieved  Into  an  RR,  the  interface  would 
simply  locate  the  current  record  of  set.typel  In  the  kb  and 
return  the  record  after  It  In  the  case  of  FIND  mext,  or  the 
record  before,  It  In  the  case  of  the  find  PRIOR,  The  fact 
that  all  of  the  member  records  of  the  set  occurrence  are 
already  In  an  RB,  eliminates  the  need  for  additional 
database  accesses.  Thus,  the  only  ABDl  request  that  need  oe 
formed  Is  thlsi 


RETRIEVE  ((TYPE  ■  record.typel)  and 

(MEMBER, set-typel  a  owner. dbkey»set«typel ) ) 
(all  attributes)  Cby  DBKEy] 


As  an  example,  consider  the  following  requesti  Find 
all  the  Dart  numbers  (PNO's)  for  parts  supplied  by  supplier 
S4,  A  possible  CODASYL  procedure  to  accomplish  this  '«ould 
be: 


MOVE  '84'  TO  SNO  IN  S 
FIND  ANY  S  USING  SNO  IN  S 
MOVE  'NO'  TO  EOF 
FIND  FIRST  SP  WITHIN  S-SP 
PERFORM  UNTIL  EOF  «  'YES' 
GET  SP 

(add  PNO  IN  SP  to  result  list) 
FIND  NEXT  SP  WITHIN  S-SP 
END.PERFORM 


The  statements  of  concern  here  are  the  find  FIRST 
and  the  FIND  NEXT,  The  reader  need  only  be  aware  that  in 
CODASYL  only  one  record  at  a  time  Is  made  available  to  the 
user.   Thus,  the  need  for  the  perform  looPt 

49 


In  response  to  the  above  sequence  of  statements,  the 
interface  would  perform  these  steps: 


Step  1:  The  kms  of  the  interface  would  form  a  retrieve 
request  to  get  all  members  of  the  S-SP  set  owned 
by  supplier  S4,  since  each  record  has  a  predicate 
wnich  identifies  them  as  members  of  a  particular 
set  occurrence,  the  task  is  fairly  easy.  The  re- 
quest is: 

RETRIEVE  ((TYPE  ■  SP)  and 

(MEMRER,S-SP  =  dblcey  of  S4)) 
(SNO,PNO,0TY)  tby  PNO] , 


The  results  of  executinq  this  request  are   shown   in  Figure 

16,   We  can  see  that  every  member  record  of  the  set  has  been 

fetched  from  the  database  and  is  available  for  return  to  the 

user.   The  FIND  FIRST  causes  the  first  record  to  be  returned 

to  the  user. 

Step  2:  Since  the  CODASYL  procedure  has  a  FIND  next 
statement,  the  same  RB  Is  l-  ■»d.  In  other  words, 
the  KC  does  not  need  to  execute  a  new  retrieve  re- 
quest. It  merely  maices  available  the  next  record 
in  the  RB  until  all  records  have  been  returned  to 
the  user  as  per  the  loop. 

Since  we  are  only  looicing  for  PNO  values,  the   interim  user 

code  would   specify  the  attribute   to  be  returned  and  the 

interface  would  respond  accordingly, 

<S4,P2,200> 
<S4,P4,300> 
<S4,P4,400> 

♦  -  —  -----  —  ---------•----♦ 

Figure  16:  Contents  of  Bufl  After  RETRIEVE, 
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5.     xba  ziUQ  qib;u£S  statftoaat 

The  FIND  OWNER  Statement  causes  the  owner  of  the 
current  o£  set.type  occurrence  to  be  returned  to  the  user. 
The  syntax  for  this  statement  is; 

FIND  OWNER  WITHIN  set-typel 

The  mapping  of  this  statement  Is  relatively  straightforward. 
The  KMS  must  simply  form  a  RETRIEVE  request  based  on 
Information  available  in  the  CIT,  Tne  KMS  examines  the  CIT 
entry  for  set.typel  and  extracts  the  owner's  type  and 
database  key  value  directly  from  the  tablet  It  is  then  an 
easy  task  to  form  the  request! 


RETRIEVE  ((TYPE  «  owner  of  set-typel)  and 

(DRKEY  a  owner  dbkey  of  set.typel)) 
(all  attributes) 


As  an  example,  suppose  we  want  to  know  the  STATUS  of 
the  supplier  for  part  number  P6«  Let  us  assume  that 
previous  statements  have  set  up  the  current  S-SP  set 
occurrence  to  be  S2/P6/20,   The  CODASYL  statement  ist 

FIND  OWNER  WITHIN  S-SP, 

In  response  to  this  request,   the   interface  takes   the 
following  actlonj 

Step  1:  The  KHS  forms  the  request: 

RETRIEVE  ((TYPE  a  S)  and 

(DBKEY  a  dbkey  of  S2)) 
(SNO,SMAME, STATUS, CITY) 
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step  2;  The  KC  would  cause  the  execution  of  the  above 
request,  resulting  In  an  RB  containlnq  one  record, 
namely,  the  S2  record. 

Based  on  the  interim  user  code,  the  STATUS  value  is  returned 

to  the  user  from  the  RB  by  the  interface, 

6,  IhA  LliiU  UllUlU   CU£ft£UX  Statastat 

This  statement  causes  the  first   record   within   the 

current   occurrence   of   set^typel   whose   values   for  Itetnl 

through   Itemn   match   those   in   the   u&ft£  naDt,     aCAA   for 

record. typel ,    The  following   syntax   Is   used   for   this 

statement. 


FIND  record. type!  within  set.typel  CURRtNT 
USING  itemi,  ,,,  , itemn  IN  record. typel 


This  statement  is  similar  to  the  FIND  nuPLICATE 
except  that  the  search  values  are  ohtained  from  the  user 
vice  the  current  record  of  set  type.  Thus,  only  a  single 
RETRIEVE  request  is  needed.   That  request  ta<es  the  tormi 


RETRIEVE  (CTPYE  s  record.typel)  and 

(MEMBER, set.typel  a  db<ey  of  owner  set.typel) 

and  (iteml  s  user  vaiuel) 

and  , , , 

and  (itemn  b  user  valuen)) 

(all  attributes)  (by  DBKeY] 


This  request  is  then  passed  to  the  KC  for  execution.  If 
there  is  more  than  one  record  satisfying  this  query,  the  RB 
for  the  request  contains  them  all.  However,  only  the  first 
record  encountered  is  returned  to  the  user. 

To  illustrate  the  process  of  this  mapping,  we  return 
to  a  previous  example?   FIND  the  first  shipment  for  supplier 
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SI  In  which  the  quantity   Is   100,    Uslna   the   first   four 
statements  from  the  examole  In  section  C,3  we  have. 


MOVE  SI  TO  SMO  IN  S 
FIND  AMV  S  USING  SNO  IM  S 
MOVE  100  TO  OTY  IN  SP 
FIND  SP  WITHIN  S-SP 

CURRENT  USING  QTY  IN  SP, 


In  order  to  carry  out  this  request,  the  following  steps   are 
taken  by  the  Interface! 

Step  li  The  KMS  forms  the  request! 

RETRIEVE  ((TYPE  s  SP) 

and  (MEMBER, S-SP  «  dblcey  of  SI) 
and  (OTY  s  100)) 
(SNO,PNO,QTy)  tby  DBKEY3 

Step  2!  The  KC  executes  the  above  request  and  causes  the 
first  record  In  the  RB  to  be  made  available  to  the 
user, 

D.   MAPPING  THE  CODASYL  GET  STATEMENTS 

The  GET  statements  In  the  CODASYL-DML  can  be  considered 
as  data  retrieval  statements  just  as  the  FIND  statements 
are,  except  that  the  GET  request  can  only  access  records 
that  have  been  previously  Identified  by  a  FIND  statement. 
It  18  the  statement  that  actually  gives  the  user  access  to 
the  individual  records.  There  are  three  options  available 
with  the  GET  statement,  and  we  examine  each  in  turn.  In 
developing  these  mappings,  we  decided  not  to  directly  map 
the  GET  statements  to  ABDL  RETRIEVE's,  but  to  simply  Issue 
instructions  to  the  KC  for  handling  them. 
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!•  Zb«  G£Z  AQd  C£i  £ftco£a.tvB«  atattaftats 

The  GET  statement,  without  the  specification  of  a 
particular  record  type,  causes  the  entire  current  record  of 
run  unit,  that  1$,  every  data  field  in  the  record,  to  be 
returned  to  the  user  via  the  User  WorK  Area  (iJ*A),  In  tne 
MLPS  network  interface,  recogniton  of  this  statnent  by  the 
KMS  results  in  the  following  responsei 

Step  1:  The  kms  informs  the  kc  that  the  "next"  available 
record  in  the  RB  that  contains  records  of 
the  type  CIT, RUN. UNIT, type  is  to  be  passed  to  the 
user,  Note  that  the  type  of  the  current  of  run 
unit  does  not  matter  in  this  case. 

The  GET  record. type  statement  is  Identical  to  the 
GET  option  alone,  with  the  exception  that  the  user  specifies 
a  particular  record  type.  In  this  case,  the  kms  must 
determine  if  the  types  of  the  current  of  run  unit  matches 
the  record  type  specified  before  issuing  instructions  to  the 
KC,   Also,  every  data  item  is  returned  to  the  user. 

Returning  to  our  example  in  section  C,4,  the  "GET 
SP"  statement  causes  the  return  of  the  record,  <S4,P2,200>, 
to  the  user  the  first  time  the  GET  is  issued  and  each  of  the 
other  records  In  sequence  as  the  loop  continues, 

UnllKe  the  other  GET  options,  this  statement  causes 
specific  data  items  to  be  returned  to  the  user.  The  syntax 
of  the  statement  isi 

GET  Iteml,  ,,,  ,ltemn  IN  record.typel. 
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The  KMS  muit  compare  the  record. type  to  the  current  o£  run 
unit  and  also  ensure  that  the  data  Items  listed  match  the 
data  Items  In  the  record  type  specified.  Once  this  Is  done 
and  Is  successful,  the  KMS  Issues  instructions  to  the  KC 
Just  as  In  the  above  case.  Only  this  time,  specific  data 
Items  are  returned  from  the  records  accessed. 

As  an  example,  suppose  we  wanted  only  the  PNo  values 
from  the  SP  records.  The  value  returned  from  our  last 
example  would  be  ?2,  with  subsequent  GET  statements 
returning  each  pno  value  In  succession, 

E,   MAPPING  THE  DATA-UPDATING  STATEMENTS 

In  this  section,  we  examine  the  CONNECT,  DISCONNECT, 
STORE,  MODIFY,  and  ERASE  statements.  At  this  point,  the 
reader  should  have  a  basic  understanding  of  the  mapping 
process  as  previously  described.  Thus,  for  the  saice  of 
brevity,  the  reader  Is  referred  to  Cftefs,  7,  9,  and  123  for 
detailed  descriptions  of  the  statements  and  any  restrictions 
Involved  with  their  use,  we  therefore,  confine  our 
discussion  of  these  statements  to  a  broad  definition,  the 
mapping  process  Itself,  and  In  most  cases,  an  example, 

1,  Xb«  COttUeCS  Stfttftfiaat 

The  CONNECT  Statement  is  used  for  manual  Insertion 
of  the  current  record  of  run  unit  into  the  current 
occurrences  of  the  set  type(s)  specified.  The  syntax  is: 

CONNECT  record.typel  TO  set.typel,  ,,,  ,set«typen. 
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This  statement  requires  that  the  record.typel  record  be  a 
member  of  the  sets  specified  and  also  have  an  Insertion 
clause  of  MANUAL  for  those  sets. 

The  CONNECT  statement   naps   directly   to   the   ABDL 
UPDATE  request.   The  UPDATE  format  1st 


UPDATE  Query  Modifier 

In  the  case  of  the  connect,  the  mapping  is  very  simple. 
First,  the  KMS  replaces  connect  by  the  word  UPDATE,  Then, 
the  type  and  database  icey  of  the  record  to  be  Inserted  Is 
taken  from  the  CIT  to  form  the  query  ((TYPE  =  record. typel) 
and  (DBKEY  a  CIT,RUN«UMT,dblcey ) ) ,  Finally,  In  order  to 
construct  the  modifier,  the  KMS  get  the  database  key  of  the 
owner  of  the  current  occurrence  set.typei  from  the  CIT,  The 
KMS  then  forms  the  modifier,  CMEMBER,set.typel  ■ 
CIT,set-typel,owner.dbicey)  for  each  set  type  specified. 
Each  set  type  specified  has  its  own  complete  UPDATE  request 
generated. 

One  might  ask,  why  use  an  UPDATE  instead  of  an 
INSERT  request,  well,  the  difference  1$  that  the  CONNECT 
statement  involves  records  already  in  the  database.  And, 
because  the  keyword,  <MEMBEP,set«type,NULL>,  Is  in  the 
record  whose  connection  value  is  NULL,  it  becomes  a  simple 
matter  to  Just  update  that  particular  keyword,  thereby 
connecting  the  record,  we  recall  that  in  an  attribute-based 
database,  keywords,  not  pointers,  are  used  to  connect  one 
record  to  another.   The  INSERT  statement  on  the  other  hand, 
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involves   records   not   already   In  the  database.   Thus,  the 
completely  translated  CHNnecT  statement  Is: 


UPDATE  CCTYPE  a  record. typel )  and 

CDBKEY  5  CIT.RUM.UMIT.dbXey)) 

(MEMBER, set.typei  =  CIT, set, typel, owner. dbicey) 


2.   Zbft  0X2CQ{iiU£CZ  StALfiffiAOt 

The  DISCONNECT  Is  just  the  opposite  of  the  co^jncct 
statement.  It  causes  the  current  record  o€  the  run  unit  to 
be  disconnected  from  the  set  listed.  The  set  occurrences 
selected  are  deterinlned  by  the  current  of  set  type 
indicators.  Since  several  set  types  may  be  listed  in  the 
statement,  only  one  statement  is  needed  in  order  to  make 
several  removals.  The  records  still  remain  in  the  database. 
They  are  simply  disconnected  from  specific  sets.  The  syntax 
ist 


DISCONNECT  record. typel  from 
set. typel,  ,,,  ,8et«typen. 


The  DISCONNECT  Statement  requires  that  record. typel 
be  a  member  of  the  set  types  listed,  and  that  the  record  be 
removed  from  the  set  occurrences  that  are  current.  Because 
of  the  way  we  represent  set  membership  in  the  attribute- 
based  record,  this  taste  is  very  simple.  Since  we  are 
disconnecting  the  current  of  run  unlt»  and  it  contains  the 
database  >ceys  of  the  owners  of  the  set  occurrences  it 
belongs  to,  and  since  each  record  can  only  be  in  one 
occurrence  of  the  same  set  type  (pairwise  dls jointness) ,  the 
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mapping  process  Is  direct.  We  slr^Ply  for-n  an  updatf  request 
for  each  set  type  listed.  Thus,  the  keyword, 
<MEMBER,set«typel, owner. dhkey>.  Is  modified,  and  becomes  the 
keyword,  <MEMBER,set.typel,NULL>,  To  accomplish  this,  the 
KMS  forms  the  request. 


UPDATE  ((TYPE  b  record. typel )  and 

(DBKEY  s  CIT,RUK'.UNIT,dbkev)) 
(MEMBER. set. typel  =  NULL) 


and  passes  It  to  the  KC  for  execution. 

The  MODIFY  statement  causes  the  entire  current 
record  of  the  run  unit  to  be  modified  or  specific  data  Items 
in  that  record  to  be  modified.   The  syntax  Is  either, 

MODIFY  record. typel,  or 
MODIFY  Iteml,  ...  ,ltemn  IN  record. typel , 

This  statement  also,  has  a  rather  straightforward 
mapping  to  the  ASDL  UPDATE  request.  The  statement  assumes 
that  the  user  has  supplied  the  necessary  data  Item  values 
for  modification  in  record. typel's  record  template  in  the 
UWA,  Therefore,  the  job  of  the  Kms  portion  of  the  Interface 
Is  to  get  this  user  supplied  Information  and  form  the 
following  UPDATE  request  for  each  data  item  to  be  modifiedi 


UPDATE  ((TYPE  a  record.typel )  and 

(DBKEY  s  CIT.RUN.UNIT.dbkey)) 
(data  Itemi  s  user  value  for  1), 


As  an  example  of  this  process,  consider  changing  the   STATUS 
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and  CITY  attributes  of  supplier  S4  from  20  and  'London'  to 
15  and  'Chicago',  resoectlvely.   The  CODASYL  request  is: 


MOVE  S4  TO  SNO  IN  S 
MOVE  15  TO  STATUS  IN  S 
MOVt:  'Chicago'  TO  CITY  IH   S 
FIND  ANY  S  USING  SNO  IN  S 
MODIFY  STATUS, CITY  IN  S, 


(Notes  The  SNO  numbers  In  this  example  are  unique.)  Once 
again  the  move  statements  set  up  tne  S  record  template  for 
use  by  holding  the  new  values  for  the  S4  record.  The  FIND 
statement  establishes  the  S4  record  as  the  current  record  of 
the  run  unit.  The  KMS  then  responds  to  the  MODIFY  statement 
by  forming  the  following  two  UPDATE  requests  and  passing 
them  to  the  KC  for  execution. 


UPDATE  ((TYPE  s  S)  and 

(DBKEY  8  dbkey  of  S4)) 
(STATUS  «  15) 

UPDATE  ((TYPE  a  S)  and 

(DBKEY  e  dbkey  of  S4)) 
(CITY  «  'Chicago') 


If  the  entire  record  was  to  be  changed,   the  first  option 
would  have  been  used,  requiring  the  KMS  to  form  an  UPDATE 
request  for  each  data  item  In  the  S  record  type, 
4,   X&A  ftZOfte  ft&AtaAC&t& 

The  STORE  statement  Is  used  In  the  COOASYL-DML  to 
Insert  a  new  record  Into  the  database.  Before  a  new  record 
can  be  inserted  though,  It  must  be  constructed.  This  taices 
place  In  the  UWA,  The  syntax  for  the  STORE  1st 

STORE  record.typel 
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In  mapping  the  STORE  statement,  care  must  be 
exercised  In  determining  the  prooer  set  occurrence  In  which 
to  place  a  record.  If  it  Is  a  member  record,  Tnls  is 
necessary  only  In  the  case  of  automatic  insertion.  The 
interface  must  have  access  to  tne  original  database 
description  in  order  to  determine  the  set  selection 
criterion  for  each  new  record  to  be  inserted.  The  three 
criterion  arei  by  APPLICATION,  by  STRUCTUHAL,  and  by  valul'. 
Each  of  these  requires  a  slightly  different  mapolng. 
Therefore,  we  examine  each  Individually, 

In  addition  to  the  set  selection  criterion,  the 
Interface  must  determine  if  any  data  items  of  the  record 
being  Inserted  has  a  DUPLICATES  NOT  ALLOWED  clause  assigned 
to  it.  In  the  case  that  such  data  items  exist,  the 
interface  must  form  a  RETRIEVE  request  to  determine  the 
existence  of  records  in  the  database  that  may  already  r\ave 
Items  with  the  same  value  as  those  In  the  record  that  is 
about  to  be  stored.  Thus,  each  STORE  statement  consists  of 
at  least  one  ABDL  RETRIEVE  and  one  Abol  INSERT  request,  Mfe 
shall  see,  however,  that  additional  RCTRIEVE's  are  necessary 
for  the  set  selection  criterion  of  structural  and  value, 

a,<  The  STORE-by»Applicatlon  Statement 

This  method  of  set  selection  assumes  that  the 
proper  occurrences  of  sets  are  Indicated  In  the  CIT, 
Therefore,  the  KMS  forms   two  requests,   the  RETRIEVE  to 
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determine  the  status  of  duplicates,  and  the  INSERT  request 

which  stores  the  record.   The  process  is  as  foiiowsJ 

Step  1:  The  kms  forms  the  RETRIEVE  below  with  the  search 
based  on  all  data  items  desianated  to  have 
DUPLICATES  NOT  ALLOWED,  The  values  for  these  items 
In  the  new  record  are  supplied  by  the  user  via 
the  UWA  record  template, 

RETRIEVECCTYPE  ■  record.typei )  and 

(data  Itemi  s   user  valuel)) 
(DBKEY)  [by  OBKEY] 

Step  2:  The  kms  forms  the  INSERT  request 

I wSERT(<TyPE, record. type! >,<D8KEY,»«*>, 
<data  itemi, user  valuei>, 
<HEM3ER,set-typei,set,typei,owner-db»«:ey>) 

and  forwards  both  requests  to  the  KC  for  execution. 

Step  3:  The  KC  issues  the  RETRIEVE  request.  If  the  RB 
returns  with  no  DBKEYs,  then  the  INSERT  request  is 
executed.  Otherwise,  the  INSERT  is  not  executed 
and  an  error  condition  exists* 

b.   The  STORE-by-Value  Statement 

The  by-VALUE  set  selection  criterion  means  that 
the  set  occurrence  we  need  has  a  data  item  whose  value  is 
equal  to  the  value  in  the  specified  UWA  record  template 
which  has  that  data  item  as  one  of  its  fields.  The  reader 
is  referred  to  Figure  10  for  the  syntax  of  the  set  selection 
clause  of  sets  S«SP  and  P»SP,  as  examples.  This  type  of 
STORE  requires  that  the  data  item  in  question  have  a 
DUPLICATES  NOT  ALLOWED  clause  also,  and  that  the  user 
initialize  the  data  item  in  its  UWA  record  template  oefore 
issuing  the  STORE  request. 

The  by-VALUE  criterion  therefore,  places  the 
additional  requirement  on  the  interface  of  locating  the 
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owner  of  the  proper  set  occurrence  before  the  new  recorfl  can 
be  inserted  Into  the  database.  This  is  accomplished  by  the 
issuance  of  a  second  retrieve  request  by  the  kc  if  the  first 
RETRIEVE,  as  mentioned  above,  returns  null.  The  steps  in 
the  process  are; 


Step  II  The  KMS  forms  the  first  RETRIEVE  as  above.  Then 
for  each  set  type  in  which  the  new  record  is  a 
member,  a  RETRIEVE  request  is  formed  to  oet  the 
owner  database  key.   The  request  1st 

RETRIEVECCTYPE  =  owner  type)  and 

(search  item  a  user  value)) 
(DBKEY)  Cby  DBKEY] , 

Step  2t  The  KMS  forms  the  following  INSERT  request: 

INSERT(<TYPE,record«typel>, 
<DBKEy,***>, 

<data  itemifuser  valuel>f 
<MEMBrR,set-typei,**»>) 


Steo  3:  The  KC  executes  the  first  RETRIEVE  to  determine  If 
duplicates  exist.  If  not,  the  regaining  RETRIEVES 
are  executed  in  turn  to  get  the  database  keys  of 
the  owners  of  the  set  occurrences  to  which  the  new 
record  belongs.  Once  these  values  are  returned, 
the  KC  finishes  building  the  INSERT  request,  and 
executes  it, 

c.   The  STORE-by-Structure  Statement 

The  by-STRUCTURAL  set   selection  criterion   Is 

similar  to  by-VALUE  except  that  the  proper  set  occurrence  is 

selected  by  coraparlng  a  data  item  value  in  one  record  type 

to  the  value  of  that  same  data  Item  in  another  record  type. 

From  our  sample  database,   we  could  have  a  by-STRUCTURAL 

clause  Indicating  that  the  SNO  value  In  S  must  equal  the  Snu 

value  in  SP,   Thus,   we  must   searcn  for  an  SP  record 
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occurrence  with  the  same  SNO  value  as  that  in  the  S  template 
In  the  UWA,  Once  again,  this  data  Item  /nust  have  a 
DUPLICATES  NOT  ALLOWED  specification. 

The  mapplnq  here  Is  Identical  to  that  for  the 
by-VAr.UE  case  except  tnat  the  second  through  1th  RETRIEVES 
are  based  on  equality  of  values  In  seoerate  records.  Since 
the  Idea  Is  the  same,  we  will  not  give  the  specifics  of  the 
mapping  here.   It  Is  presented  in  detail  In  the  Appendix, 

5.  ibe  erase;  stAtADft&t& 

The  ERASE  Is  the  final  CODAsYL-DML  statement  we 
consider  for  the  MLDS  networic  interface.  As  Implied,  It  Is 
the  statement  that  causes  deletion  of  records  from  the 
database.  There  are  two  options  with  this  statement,  as 
previously  discussed  In  Chapter  2,  we  begin  with  the  simple 
ERASE,   The  syntax  for  this  ERASE  statement  Is: 

ERASE  record.typei 

The  ERASE  without  the  ALL  option  deletes  one  record 
from  the  database,  namely,  the  current  record  of  the  run 
unit.  The  only  requirement  is  that  the  record  Is  not  the 
owner  of  a  non-empty  set.  This  means  that  in  mapping  this 
statement,  we  need  to  issue  a  RETRIEVE  request  prior  to  the 
deletion  request  to  determine  if  there  are  any  sets  whose 
members  are  connected  to  this  record.  Therefore,  for  each 
set  type  in  which  the  current  of  run  unit  is  an  owner,  we 
have  a  predicate  in  the  RETRIEVE  query  of  the  form: 
(MEMBER, set. typel  «  CIT, RUN. UNIT, db<ey) ,   The  request   1st 

63 


RETRIEVE((MEMBER,set-tyDel    a   CIT, PUN. UNIT, dblcey) and 

: 
•  and 

(MEMBER, set. typen  s  CIT.RuN.UNIT.dbkey) ) 
(DBKEY)  [by  DBKEY] , 


The  next  step  In  the  mapplnq  process  Is  to  form  a 
DELETE  request  that  deletes  the  current  of  run  unit.  That 
request  Is: 


DELETE((TYPE  «  CIT.RUN.UNIT, type)  and 
(DBKEY  ■  CIT.RUN.UNIT.dbKey)). 


So,  the  KMs  In  this  case  Issues  two  ABdl  requests  to  the  KC 
for  execution.  The  KC  would  execute  the  RiiiTRIEVE  first.  If 
it  results  in  a  NULL  RB,  then  the  DELETE  is  executed. 
Otherwise,  the  ERASE  fails. 

The  second  ERASE  under  consideration   is   the  ERASE 
with  the  ALL  option.   The  ERASE  ALL  syntax  is: 

ERASE  ALL  record.typel , 

As  mentioned  in  Chapter  7,  this  option  is  liice  a  "vacuum 
cleaner"  In  that  it  deletes  every  record  in  the  hierarchy 
starting  with  the  current  record  of  the  run  unit,  Tne 
difference  between  the  mapping  of  this  statement  and  the 
previous  ERASE  is  that,  RETRIEVES  must  be  formed  to  get  the 
database  keys  of  each  member  of  every  set  that  the  current 
of  run  unit  owns,  and  then  RETRIEVES  are  formed  recursively 
thereafter   for   the  members   of  lower  level  sets  until  the 
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leaves  of  the  hierarchy  are  reached,  in  addition  to  these 
RETRIEVE  requests,  a  DELETE  request  Is  needed  for  each 
member  of  every  set  connected  to  the  current  ot  run  unit  and 
the  current  of  run  unit  Itself,  As  one  can  see,  this  could 
become  quite  complex.  Therefore,  we  briefly  decrlbe  the 
alqorlthm,  and  refer  the  reader  to  the  Appendix  for  the 
details. 

In  mapplnq  the  ERASE  ALL,  the  KMS  forms  a  RETRIEVE 
request  to  qet  each  member  of  every  set  owned  by  the  current 
of  run  unit.  It  then  forms  a  DELETE  for  each  of  these 
members.  Once  It  nas  taken  care  of  the  first  level,  the  kms 
proceeds  to  form  requests  which  erase  all  of  the  descendents 
in  the  same  fashion  by  calling  a  recursive  procedure  called 
"erase.all".  Finally,  the  KMS  forms  a  DLLETE  request  to 
delete  the  current  record  of  the  run  unit  as  in  the  previous 
ERASE,  This  concludes  the  desclptions  of  the  mapplnq 
process  from  CODASYL-Dml  to  ABDL, 
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In  Chapter  1,  we  provide  a  brief  description  of  the  four 
modules  Included  In  the  CODASYL  language  Interface,  nannely, 
the  lanauage  Interface  layer  (LID,  the  kernel  mapping 
system  (KMS),  the  kernel  controller  (KC),  and  the  kernel 
formatting  system  (KFS),  In  this  chapter,  we  present 
considerations  for  the  Implementation  of  the  KMS  and  the  KC, 

A,   THE  KERNEL  MAPPING  SYSTEM  (KMS) 

The  KMS  Is  the  second  module  in  the  «LOS  CODASYL 
interface.  It  is  called  from  the  language  interface  layer 
(LID  When  the  LIL  receives  CODASYL  input  requests  from  the 
user.  In  this  section,  we  discuss  the  specification  of  the 
KMS  (see  Appendix)  for  the  network  (CODASYL)  interface,  we 
describe  its  operation,  present  a  conceotual  view  of  its 
data  structures,  and  give  an  example  of  the  KMs  translation 
process.  Implementations  of  the  KMS  for  the  DL/I  and  SOL 
Interfaces  can  be  found  in  tRef,  5jpp,  45-80)  and  CRef, 
6!pp,  47-68],  respectively.  These  implementations  provided 
the  basic  framework  for  the  design  of  the  CODASYL  kms. 

The  KMS  must  perform  the  following  functionsi  (1)  parse 
the  request  to  validate  the  user's  CODASYL  syntax,  and  (2) 
translate,  or  map,  the  request  to  equivalent  ABDL  requests. 
Once  the  necessary  abdl  requests  have  been  formed,  they  are 
made  available  to  the  kernel  controller  (KC)  for  execution, 
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1.  Zba  l^iiS  £&£&££/ l]:a&slalQ£ 

The  grammar-driven  parser  Is  the  most  Important 
aspect  of  the  kms.  The  Yet-Another-Comoller  Compiler  (YACC) 
[Ref,  143  Is  an  Ideal  choice  for  the  construction  of  the 
parsert  YACC  Is  a  program  generator  designed  for  syntactic 
processing  of  token  streams.  YACC  functions  as  followsi  It 
must  be  given  a  specification  of  the  input  language 
structure  (a  set  of  grammar  rules),  the  code  tnat  is  to  be 
invoked  when  the  grammar  rules  are  recognized,  and  a  low- 
level  input  routine  that  generates  tokens  froti  a  regular 
expression  input.  Given  these  inputs,  YACC  generates  a 
program  that  syntactically  recognizes  the  input  language, 
and  causes  specific  user  code  to  be  invoiced,  as  required, 
throughout  the  recogniton  process.  The  user's  code  here  is 
the  code  that  performs  the  CODASYL-DMl  to  ABDL  translation. 
The  Lexical  Analyzer  Generator  (LEX)  tRef,  15]  is  the  low- 
level  input  routine  that  we  oropose,  LEX  is  a  program 
generator  designed  for  lexical  processing  of  input  character 
streams.  It  takes  regular  expressions  as  input,  and 
generates  a  program  that  partitions  the  input  stream  into 
tokens.  These  tokens  are  then  output  to  the  parser  for 
further  processing. 

The  parser  produced  by  YACC  consists  of  a  finite- 
state  automaton  with  a  stack.  It  performs  a  top-down  parse, 
with  left-to-right  scan  and  one  token  look-ahead.  Control 
flow  within  the  parser  begins  at  tne  highest-level  grammar 
rule.   It  then  descends  through  the  grammar,  hierarchically, 
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calling  lower-  and  lower-level  grammar  rules  whicn  search 
for  the  appropriate  tokens  in  tne  Input  streams.  As  these 
tokens  are  recognized,  some  portions  of  the 
mapping/translation  code  may  be  invoked  directly,  in  other 
cases,  these  tokens  are  propagated  oack  up  the  grammar 
hierarchy  until  a  higher-level  grammar  rule  is  satisfied. 
Once  a  rule  is  satisfied,  further  translation  can  be 
accomplished.  When  all  of  the  necessary  low-level  grammar 
rules  have  been  satisfied,  and  control  has  propagated  back 
UP  to  the  hignest-level  rule,  the  parsing  and  mapping 
process  is  complete.  In  section  6,  we  provide  an  example  of 
the  parsing  and  translation  process, 
2,   Zbg  i^MS  Oat«  StSUCtUCAft 

The  KMS  needs  several  different  data  structures. 
However,  we  confine  our  discussion  nere  to  the  structures 
which  carry  the  information  necessary  for  the  proper 
execution  of  the  translated  requests.  The  structures  that 
fall  into  this  category,  are  the  CIT  structure,  and  the 
request  nodes  which  are  passed  to  the  KC  for  execution,  A 
description  of  the  minimum  requirements  for  these  structures 
is  given  below. 

The  CIT  is  described  in  Chapter  4,  This  structure 
carries  all  of  the  currency  Information  for  a  particular  run 
unit,  and  is  vital  to  the  proper  translation  and  execution 
of  CODAsyL  statements.  The  LIL  of  the  interface  initializes 
the  CIT,  The  KMS  has  read  access  to  the  CIT  at  all  times, 
while  all  updates   of  the  CIT  are  done  by  the  KC  only.   In 
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the  following  sections,  we  discuss  each  of  the  data 
structures  that  are  directly  related  to  the  parslnq  and 
translation  process* 

a.   The  'find.node'  Data  Structure 

The  flnd.node  Is  created  and  used  any  time  that 
a  COOASYL  FIND  stateirent  is  mapped  by  the  K^S,  Since  we  are 
considering  the  implementation  of  six  different  FIND 
formats,  we  must  ensure  that  the  find.node  has  at  least  four 
fields,  one  identifying  the  node  as  a  find.node,  a  second, 
specifying  the  type  of  FIND  statement  that  must  be  executed, 
i.e.,  FIND  ANY,  FIND  CURRENT,  FIND  OWNER,  and  FIND  WITHIN, 
one  field  to  indicate  the  set  type  involved,  and  one  field 
to  identify  the  record  type  used  in  the  stateraent. 

f ind.node 


FIND 

type  of  FIND 
set  type 
record  type 

« 

pointer  to  ABDL  requestCs) 

Figure  17t  The  'find.node'  Data  structure. 

In  addition  to  the  above  information,  each 
find.node  must  also  have  a  field  which  contains  a  pointer  to 
the  specific  ABDL  request  that  resulted  from  the  mapping 
process,  with  regard  to  the  FIND  CURRENT  request  and  the 
FIND  DUPLICATE  request,   no  ABDL  request   is  generated. 
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Therefore,   the   pointer   would   be   null.    Figure  17  above 
Illustrates  the  type  of  structure  described,  where  the   dots 
represent     any     additional     imple(Dentatlon»dependent 
Information  which  might  need  to  be  Included, 
b.   The  'get. node'  Data  Structure 

The  get  node  carries  the  Information  that  the  KC 
needs  In  order  to  return  the  proper  data  to  the  user.  It 
must  have  a  field  Identifying  It  as  a  get  node  and  a  field 
Identifying  the  type  of  GET  format  being  used. 
Additionally,  a  field  Identifying  the  record  type  in 
question  must  also  be  Included,  In  the  case  of  the  GET 
Item. list  format,  the  node  should  Include  a  pointer  to  a 
list  of  data  Item  values  to  be  returned.  If  the  foriftat  It 
GET  record. type,  the  pointer  field  would  be  NULL,  and  the  KC 
would  return  all  attributes  of  the  record.  The  same  Is  true 
for  the  simple  GET  format.  Figure  18  is  an  example  of  this 
type  of  structure. 


get. node 

GET 

type  of  GET 

record  type 

• 


pointer  to  list  of  data 
items  to  be  returned 


Figure  18i  The  'get. node'  Data  structure. 
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c.  The  'connect, node'  Data  Structure 

The  connect.node  is  created  ana  used  ;*henever  a 
CONNECT  statement  is  mapped  by  the  KhS,  There  are  two 
primary  fields  In  this  node.  The  first  field  identifies  the 
node  as  a  connect.node.  The  second  field  is  a  pointer  to 
the  list  of  ABDL  UPDATE  requests  generated  by  the  KMS  durinq 
its  arammar-driven  parse.  This  list  may  contain  one  or  more 
requests  depending  upon  the  number  of  sets  that  the  record 
must  be  connected  to,  as  described  in  Chapter  4,  Under  the 
current  iinplementation  of  the  MBDS,  a  seperate  UPDATE 
request  must  be  executed  for  each  attribute  in  a  record  that 
is  to  be  changed.  Thus,  the  need  for  multiple  UPDATE 
requests.  Recall,  that  the  attribute  to  be  changed  in  this 
case  is  the  member, set.type  attribute.  Figure  19  shows  the 
basic  structure  for  this  node* 

connect.node 
CONNECT 

pointer  to  list  of  UPDATE 

requests 
^••..•.•••.•..•••...•••.••••••^ 

Figure  I9i  The  'connect^node'  Data  Structure, 

d.  The  'dlsconnect.node'  Data  Structure 

The  dlsconnect.node  is  created  and  used  whenever 
a  DISCONNECT  statement  is  encountered  by  the  KMS,  The 
fields  of  this  node  are  exactly  the  same  as   those  of   the 
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connect. node.    In   this   case   however*   the   value   of  the 
attribute  member, set. tyoe  Is  set  to  MULL,  disconnecting   the 
record  from  designated  set  occurrences.   Once  again,  we  have 
an  identifier  field,  and  a  list  of  UPDATE  requests, 
e.   The  'modify. node'  Data  Structure 

As  with  the  disconnect. node,  the  modify. node  is 
also  very  similar  to  the  connect. node.  It  is  created 
whenever  a  mouify  statement  is  encountered  by  the  KMS,  It 
has  two  fields,  an  identifier  field,  and  a  oointer  to  a  list 
of  UPDATE  requests.  The  update  requests  in  the  modify.node 
are  used  to  alter  the  value  of  specific  dft&a  itfttt  attributes 
within  a  particular  record.  The  number  of  requests  on  this 
list  can  vary  from  one  to  the  maximum  number  of  data  Items 
in  the  record,  depending  on  the  MODIFY  format  chosen  by   the 
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•  The  kstore.node*  Data  Structure 


The  store.node  is  the  most  interesting  of  the 
data  structures  presented  so  far.  It  must  contain  at  least 
four  fields.  The  first  is  tne  identifier  tleld.  The  second 
field  is  a  pointer  to  a  RETRIEVE  request.  This  request  is 
generated  by  the  KMS  In  order  to  determine  the  existence  of 
duplicate  values  for  data  items  declared  to  have  DUPLICATES 
NOT  allOk/ED  in  the  database  schema.  The  third  field  of 
importance  relates  to  the  set  selection  criterion  for  the 
record  being  stored.  It  is  generated  to  retrieve  the  owner 
database  iceyCs)  of  the  proper   set  occurrenceCs)  for  the  new 
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record.   This  request  is  only  generated  In  the  cases  of   the 
by-VALUE  and  by-STRUCTURAL  set  selection  criterlons. 


store.node 

STORE 

pointer  to  duplicate  FETRIEVP  request 
pointer  to  list  of  set  select  REIRIEVE 
requests 


pointer  to  INSERT  request 
Figure  20:  The  'store. noae'  Data  Structure, 


The  final  field  required  for  the  store.node  Is  a 
pointer  to  the  INSERT  request  which  will  actually  cause  the 
record  to  be  placed  into  the  database.  Figure  20  above  is 
an  illustration  of  this  data  structure.  As  mentioned 
before,  the  dots  In  the  figure  represent  additional 
implementation-dependent  informatioh.  Should  the  set 
selection  criterion  be  by  APPLICATION,  the  second  RETRIEVE 
pointer  would  be  NULL. 

g.  The  'erase.node'  Data  Structure 

The  final  data  structure  we  discuss  is  the 
erase.hode.  This  node  is  created  whenever  an  ERASE 
statement  is  mapped  by  the  KMS,  If  the  EhASE  without  the 
ALL  option  is  mapped,  the  erase.node  must  contain  the 
following  four  fields.  First,  it  must  contain  an  identifier 
field.  Second,  it  must  contain  a  type  field  with  a  value  of 
NULL,  Indicating  that  it  does  not  have  the  ALL  option.   The 
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third  field  In  this  node  must  be  a  pointer  to  the  RETRIEVE 
request  that  will  determine  If  the  record  being  deleted  owns 
a  non-empty  set.  Should  this  request  return  NULL,  tne  KC 
would  execute  the  request  stored  in  the  fourth  field.  This 
Is  the  field  containing  a  pointer  to  the  DELtTE  request  that 
will  delete  the  current  record  of  the  run  unit.  Figure  21 
gives  a  representation  of  this  structure. 


erase.node 

ERASE 

type  of  ERASE 

pointer  to  RETRIEVE  request 

0 
t 

pointer  to  run. unit  DELETE 

^•••••••••.••-••••••••••••••.•••^ 

Figure  21i  The  'erase.node'  without  the  ALL  Option, 


The  erase. node  created  for  the  ERASE  vitb  the 
ALL  option  will  be  considarably  inore  complex  than  the 
previous  case.  First,  there  must  be  an  identifier  field  and 
a  type  field.  Then  there  must  be  two  pointer  fields.  The 
first  pointer  field  will  point  to  tne  list  of  RETRIEVE 
requests  generated  to  get  all  the  descendents  of  the  record 
being  delated.  The  second  pointer  field  will  point  to  the 
list  of  DELETE  requests  generated  for  each  of  the  descendent 
records.  Finally,  the  last  field  in  the  structure  should  be 
a  pointer  to  the  DELETE  request  that  deletes  the  current 
record  of  the  run  unit.  Figure  22  is  an  example  of  this 
structure, 
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erase.node 

I  ERASE 

I  type  of  ERASE  (ALL) 

I  pointer  to  descendent  Retrieves 

I  pointer  to  descenaent  DELETES 

I 

I 

i 

I 

I  pointer  to  DELETE 


Figure  22;  Tne  'erase. node'  with  all  option, 

B,   THE  MAPPING  PROCESS!   AN  EXAMPLE 

In  tnis  section,  we  present  an  Illustrative  example  of 
the  parsing  and  translation  processes  within  the  Kms, 
Recall  from  the  previous  chapter,  that  not  all  of  the 
teatures  of  CODASYL  are  incorporated  in  our  specification. 
Additionally,  since  we  have  thoroughly  covered  the  mappings 
in  the  previous  chapter,  we  do  not  discuss  these 
translations  in  detail. 

As  an  example  of  the  KMS  mapping  process,  we  use  a 
simple  CODASYL  MODIFY  request.  Me  begin  our  example  by 
showing  the  dml.statement  portion  of  the  KMS,  we  then  step 
through  the  grammar  and  demonstrate  relevant  portions  of  our 
design  in  a  system  specification  language  CSSL),  The  reader 
should  note  that  throughout  the  example,  we  only  show  the 
portions  of  the  SSL  that  would  actually  be  executed.  The 
entire  kms  design  is  shown  in  the  Appendix,  The  portion  of 
the   grammar  relevant  to  this  example  is  shown  In  Figure  23, 
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In  Flqure  23,  we  have  Included  the  orammar  rules   onlv,   and 
not  the  code  to  be  Invoked  as  eacn  rule  Is  satisfied. 


statementt  ddl. statement 
I  dml 

; 

d.Til:  dml.statement 

I  dml  dml.statement 

; 

dml. statements  set. flag 

move 
get 
find 
store 
connect 
disconnect 
erase 
modify 

perform. loop 
If-tnen 

; 

modify;  MODIFY  Item.llst  IN  record-type 
I  MODIFY  record. type 

; 

item. lists  Item. name 

I  item. list  COMMA  item.name 

; 

record. types  IDENTIFIER 

; 

item.names  IDENTIFIER 
Figure  23i  The  KMS  dml.statement  Grammar. 


The  source  CODASYL  procedure  we  use  for  our  example  is: 


MOVE  100  TO  OTY  IN  SP 
MODIFY  OTY  IN  SP, 


Before  giving  the  abdl  equivalent  of  this  request,   however, 
we   must   make  the  assumption  that  the  record  being  modified 
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Is  the  current  record  of  the  run  unit,  we  also  assutie  that 
the  database  key  for  this  record  is  10,  iwlth  these  two 
assumptions  In  inind,  the  ABOI.  equivalent  of  the  MODIFY 
statement  Isj 


[UPDATE  ((TFMPLATE  =  SP)    and  (DBKEY  s  10)) 
(OTY  s  100)3  , 


For  the  sake  of  brevity  In  our  example,  we  will  not  go 
through  the  mapping  process  for  the  MOVE  statement.  The 
reader  need  only  be  aware  that  the  new  value  for  the 
attribute  QTY  in  the  record  template  for  record  type  SP,  has 
been  set  to  the  value,  100,  by  the  previous 
parse/translation.  Now,  we  may  proceed  with  the  mapping  of 
the  MODIFY  statement. 

At  the  beginning  of  the  mapping  process,  the  oarse 
descends  the  grammar  hierarchy  searching  for  tokens  in  the 
grammar  rules  which  match  those  in  the  Input,  Notice  that 
the  first  rule  to  be  tried  is  the  ddl-statement  rule.  As 
the  parse  descends  the  ddl. statement  rule,  hierarchically, 
there  are  no  tokens  which  match  the  examole  input  stream. 
Thus,  the  ddl-statement  rule  is  not  satisfied,  and  the  parse 
begins  again  at  the  dml  rule. 

When  the  dml  rule  is  called,  it  immediately  calls  the 
dml.statement  rule, 
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dml. statement  3  set.flag 

move 
get 
find 
store 
connect 
alsconnect 
erase 
modify 

perf orm.ioop 
If. then 
1    • 


The  dml. statement  rule  then  calls  the  set.flag  rule.  The 
set.flag  rule  Is  not  satisfied,  however,  and  the  move  rule 
is  called.  It  too,  is  not  satisfied.  So,  the  process  of 
checking  each  successive  rule  is  continued  until  we  reach 
the  following  rulei 


modifvi  MODIFY 
< 
select.list  8  NULL 

Item.list  IN  record.tvpe 
< 

/*  error  checks  are  made  here  ♦/ 
alloc  and  Inlt  new  'modify'  node 


•  •  • 


for  (each  data.item  on  select.list) 
alloc  and  inlt  new  abdl.str 
/♦  form  UPDATE  request  ♦/ 
copy  "[UPDATE  ((TEMPLATE  b  'record, type* ) 
and  (DBKEY  «  CIT, RUN, UNIT, dblcey))" 
to  abdl.str 
get  'item. value'  from  move. list 
concat  "('data.item'  b  'item. value')] 

to  abdl.str 
connect  abdl.str  to  'modify'  node 
end. for 
end.else 
) 
I  MODIFY  record.type 

The  modify  rule  looks  for  the  token,  MODIFY,  in   the   Input. 
Since   it  is  present,  the  first  portion  of  the  rule  matches, 
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and  the  code  following  the  toicen  in  the  rule  Is  invoked. 
This  code  simply  resets  a  local  list  which  win  eventually 
contain  the  names  of  the  data  items  which  are  to  be 
modified. 

The  next  rule  called  is  the  4LtAB^lift£  rule.  This  rule 
searches  for  a  list  of  identifiers  in  the  input  by  callinq 
the  item. name  rule,  and  recursively  callim  item. list,  as 
indicated.  In  our  example,  the  single  identifier,  QTY, 
satisfies  the  first  portion  of  this  ruie,  namely,  item, name. 
Thus,  the  item. list  rule  is  satisfied.  The  syntax  for  the 
item. list  rule  is: 


item.iistJ  item.name 

< 
add  the  item.name 

to  select. list 
> 
item.list  COMMA  item.name 
< 
add  succesive 

Item.name  to  selec^list 
} 
t      • 


The  next  portion  of  the  modify  rule  Is  the  token,  IN, 
This  token  matches  the  token,  in,  in  the  input  stream,  and 
the  parse  continues.  Finally,  the  last  portion  of  the 
modify  rule  which  must  oe  satisfied  is  the  sAca&d.t){BA  rule. 
This  rule  is  satisfied  by  matching  the  identifier,  SP,  in 
the  input,  with  the  token,  IDENTIFIER,  in  the  record. type 
rule.   After  matching  these  two,  the  entire  modify  rule  is 
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satisfied,  and  the  Invocation  of  the  refnalnlng  mapping  and 
translation  code  following  the  rule  taices  place. 

The  mapping  and  translation  occurs  as  follows.  First,  a 
series  of  checks  are  made  to  determine  if  the  record  being 
modified  Is  the  current  record  of  the  run  unit.  If  the  new 
value(s)  have  been  placed  In  the  record  temolate,  and  If  all 
of  the  Items  Identified  In  the  Item  list  belong  to  the 
record  in  guestlon.  Then,  a  modify  node  Is  created. 
Following  this  step,  an  UPDATE  reguest  Is  generated  for  each 
of  the  data  items  being  modified.  Finally,  each  of  the 
update  reguests  are  connected  to  the  modify  node  for 
execution  by  the  KC«  t^fith  the  mapping  and  translation  code 
executed,  the  modify  rule  is  completely  satisfied,  and 
control  propagates  back  up  the  grammar  hierarchy  to  the  dml 
rule  which  checks  for  more  input. 

As  one  can  see,  quite  a  significant  amount  of  work  is 
done  by  the  KMS  in  preparing  reguests  for  use  by  the  kc.  We 
feel  that  by  adequately  providing  information  to  the  KC#   we 


greatly  reduce   the  amount  of  work  that  must  be  done  by  the 


KCt   This  means  less  coding  for  the  implementor  and fhould 

lead  to  less  complexity  In  the  KC« 

C,   THE  KERNEL  CONTROLLER  (KC) 

The  KC  is  the  third  module  in  the  MLDS  CODASYL 
interface.  It  is  called  by  the  lanquage  interface  layer 
(LID  when  a  new  database  is  being  loaded,  and  is  called  by 
the  kernel  mapping  system  (KMS)  when  an  existing  database  is 
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being  manipulated.  The  KC  Is  the  module  which  performs  the 
task  of  controlling  the  submission  of  ABDL  transactions  to 
the  multl-bacicend  database  system  (mbhS)  for  processing. 
Implementations  of  the  KC  for  the  DL/I  and  SQL  Interfaces 
can  be  found  In  fRef,  5:pp,  84-105J  and  CRef,  6:pp,  69-89], 
respectively. 

The  KC  must  perform  the  following  functions:  Cl)  submit 
transactions  to  the  mbds,  (2)  receive  and  store  results  of 
transactions,  (3)  update  the  currency  indicator  table,  and 
(4)  cause  the  proper  data  to  be  returned  to  the  user, 

i,  Zba  S££UCtUCt  Qt  Ihk   KC 

Because  of  the  large  number  of  types  of  transactions 
that  the  KC  must  process,  we  suggest  that  the  overall 
structure  of  the  KC  be  based  on  the  "case"  control 
structure.  At  tne  top  of  the  control  structure  Is  a  master 
control  procedure  which  Is  responsible  for  Initialization  of 
variables,  pointers,  and  data  structures,  as  well  as, 
deciding  the  type  of  ABDL  transaction  that  Is  being 
processed.  Recall  that  there  are  two  major  types  of 
transactions,  creation  of  a  new  database,  and  manipulation 
of  an  existing  database.  Thus,  a  two  element  case  Is 
regulred  In  the  master  control  procedure.  These  cases  are 
then  used  to  call  subsequent  procedures  and  functions  which 
handle  the  transactions  which  fall  under  the  above 
categories. 
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a.   Creation  of  a  New  Database 

The  creation  of  a  new  database  Is  the  least 
difficult  transaction  that  the  KC  win  nanile.  It  Involves 
loading  the  COOASYL  schema  created  by  the  KM5  Into   the   kds 


(MBDS),  In  its  attribute-cased  form*  It  is  also  responsible 
for  mass  storage  of  new  records  during  a  database  creatjpn 
transaction.   Thus,  the  KC  must  also  assign  database  iceys  to 


the  new  records  throughout  this  proces8,_ 

Currently,  work  is  being  done  on  the  algorithms 


necessary  to  accomplish  the  transformations  above  and  the_ 
mass  storage  requirement.  This  work  will  not  be  completed 
in  time  for  inclusion  in  this  thesis.  Suffice  it  to  say, 
however,  that  once  the  work  is  completed,  the  only 
requirement  of  the  KC  in  this  case,  is  to  call  a  procedure 
to  load  the  database  schema,  call  a  procedure  to  load  the 
database  descriptor  file,  and  then  can  a  procedure  to  lo«SL 


the  new  database.   Once  these  procedures   are  executed, 
control  is  returned  to  the  LIL, 

b.   Manipulation  of  an  Existing  Database 

The  manipulation  of  an  existing  database  can 
also  be  divided  Into  subleases.  There  are  the  data 
retrieval  requests  and  the  database  update  requests. 
However,  all  of  these  can  be  handled  by  a  single  case 
structure.  Recall  that  each  time  the  KC  is  callei,  a 
request  node  of  some  type  is  made  available  to  the  KC, 
These  request  nodes  are  then  used  to  determine  which  option 
within  the  case  structure  to  execute.   The  structure  is 
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Illustrated  in  Figure  24,  in  the  following  sections,  we 
present  the  procedural  requirements  for  each  type  of  data 
manipulation  transaction, 

case  op. type  of 

create.db:  call  load.schema 

call  load. descriptors 
call  load.dp.recs 

find!  case  type  of 

any:  call  find. any 
current;  call  find. current 
duplicate!  call  find. duplicate 
(first, last, 

next, prior):  call  flnd.conseq 
owner:  call  find. owner 
end. case; 
(connect, 
disconnect, modif y) t  call  update. db 

; 

store:  call  store.rec 
; 

erase:  call  delete.recs 

; 

get!  call  get.rec 
; 

Figure  24:  The  KC  Control  Structure, 

(i)  Z&a  Ziau  esACAdusftfi.  mere  are  six  basic 
types  of  FIND  requests  utilized  in  our  system.  The  first  of 
these  is  the  FIND  ANY  request,  upon  encountering  a 
find. node  whose  type  field  is  any,  the  find. any  procedure  is 
calledt  This  procedure  sets  up  the  request  buffer  to 
receive  any  results  that  may  be  returned.  It  tnen  issues 
the  request  to  the  KDS,  Upon  return  from  the  KDS,  the 
find.any  procedure  must  update  the  CIT,  based  on  the  type 
and  database  )cey  of  the  record  that  is  the  first  record  in 
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the  request  buffer,  A  pointer  Is  then  set  to  point  to  this 
record  In  preparation  for  returning  It  to  the  user.  The 
record  Is  not  returned  though,  unless  the  user  Issues  a  GET 
request. 

If  the  request  Is  a  FiNO  CURRENT  request, 
the  find. current  procedure  Is  called.  Its  job  Is  quite 
easy.  It  must  simply  update  the  CIT,  oy  settlnq  the  current 
of  run  unit  Indicator  to  the  type  and  database  key  of  the 
current  record  of  the  set  type  specified  In  the  request 
node. 

When  the  request  Is  a  FIND  DUPLICATE 
request,  the  f Ind.dupllcate  procedure  is  called.  This 
procedure  assumes  that  the  records  belnq  requested  are 
already  In  a  request  buffer.  Thus,  the  only  information 
required  from  the  find. node  Is  the  record.type  being 
searched  for,  the  set^type  of  Interest,  and  the  data  Item 
values  on  which  the  search  Is  based.  The  procedure  locates 
the  request  buffer^  and  sets  a  pointer  to  point  to  the  first 
duplicate  record  found.  This  record  then  becomes  the  record 
returned  when  the  user  issues  a  GET  request.  The  procedure 
also  updates  the  CIT  accordingly. 

The  next  type  of  FIND  request  Is  the  FIND 
FIRST,  LAST,  NEXT,  or  PRIOR,  In  these  cases,  if  the  type  is 
first,  last,  next,  or  prior,  the  flnd.conseq  procedure  is 
called.  It  bases  Its  performance  on  the  type  of  the 
find.node.  If  the  type  is  next  or  prior,  the  procedure 
assumes   that   the   records  are  already  in  a  request  buffer, 
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It  looks  for  the  correct  request  ouffer  based  on  the 
record.type  specified  in  the  flnd.node,  and  sets  a  pointer 
to  point  to  the  next  or  prior  record  relative  to  the  current 
record  of  the  set  type  this  buffer  Is  holding.  In  other 
words,  each  record  in  the  buffer  is  a  member  of  the  current 
set  type  occurrence,  and  the  find.conseq  procedure  simply 
points  to  the  record  before  or  after  tne  current  record  for 
that  set.  Once  again,  this  is  the  record  returned  when  the 
user  issues  a  GET  request. 

If  the  type  of  the  FIND  is  first  or  last, 
the  find.conseq  procedure  does  the  following.  First,  it 
checks  to  see  if  a  request  buffer  exists  for  the  set  type 
requested  in  the  find.node.  If  no  such  buffer  exists,  the 
procedure  creates  a  request  buffer  and  issues  the  RETRIEVE 
request  attached  to  the  find.node.  The  results  of  the 
request  are  then  placed  in  the  new  request  buffer,  and  a 
pointer  Is  set  to  point  to  the  "first"  or  "last"  record  in 
the  set  for  return  to  the  user. 

The  next  type  of  find  request  is  the  find 
OWNER,  When  this  is  the  type  of  the  find.node,  the 
find.owner  procedure  is  called.  It's  function  is  fairly 
straightforward,  A  request  buffer  is  created  to  hold  the 
record  that  is  the  owner  record  of  the  set  type  indicated  in 
the  find.node.  The  find.owner  procedure  then  issues  the 
RETRIEVE  request  attached  to  the  find.node,  and  prepares  the 
record  for  return  to  the  user. 
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The  final  type  of  find  request,  expected  by 
the  KC,  Is  the  FIMD  within  CLjRRENT  request.  Tn  this  case, 
the  find. within  procedure  Is  called.  The  procedure  creates 
a  request  ouffer  for  the  storaae  of  records  returned  and 
Issues  the  RETRIEVE  request  associated  with  the  current 
find. node.  Again,  a  pointer  is  set  to  point  to  the  first 
record  in  the  request  buffer  In  order  that  this  record  'niaht 
be  returned  when  a  GET  request  Is  Issued  by  the  user.  It 
Should  be  noted  that  In  each  case  above,  the  CIT  Is  updated 
unless  a  currency  suppression  list  has  been  attached  to  the 
find, node  In  question, 

(2)  XUft  CQUUZLl,  Ql&CQtiU&Ql,  A&d  ttOOICX 
SsosaducAft,  The  connect,  disconnect,  and  MODIFY  requests 
are  handled  by  the  KC  in  the  same  general  manner,  i««hen 
either  a  modify. node,  a  connect.node,  or  a  dlsconnect.node 
is  encountered  by  the  KC,  the  procedure,  update.db,  is 
called.  If  the  node  is  a  modif y.node,  the  KC  simply  submits 
the  attached  ABDL  UPDATE  requests  to  the  KDS  for  execution. 
After  execution,   control  is  returned  to  the  LIL, 

If  the  node  passed  to  proceddure  update.db 
is  a  connect.node  or  a  disconnect.node,  all  of  the  above 
applies,  except  that  before  giving  control  to  the  LiL,  the 
KC  must  update  the  CIT,  When  a  record  is  connected  to  a  set 
type,  that  record  becomes  the  current  record  of  the  set 
type.  When  a  record  is  disconnected  from  a  set  type,  the 
entry  in  for  that  set  type  in  the  CIT  is  set  to  NULL  and 
remains  so  until  another  record  of  the  set  type  is  accessed, 
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(3)  ihA  SIQft£  esocadusA,  When  the  KC 
recognizes  a  store.node,  the  procedure  store«rec  is  called. 
The  first  task  performed  by  store.rec  Is  to  execute  the 
first  RETRIEVE  request  attached  to  the  node.  This  request 
determines  If  there  are  records  In  tne  database  which  have 
attribute  values  that  are  not  to  be  duollcated.  If  the 
request  buffer  created  for  this  RETRlEve  Is  ooo-ftoetif  at  the 
end  of  execution,  there  Is  an  error.  If  the  request  buffer 
Is  Afifitu  »  then  store.rec  performs  in  the  followlnq  mannert 
For  each  RETRIEVE  request  on  the  set  select  RETRIEVE  list,  a 
file  buffer  Is  created  and  the  RETRIEVE  request  is  issued. 
These  requests  return  the  database  keys  of  the  owners  of  the 
set  occurrences  to  which  the  new  record  belonqs. 

After  execution  of  the  set  select  RETRIEVE 
list,  the  procedure  store.rec  then  assigns  a  database  key  to 
the  new  record,  and  proceeds  to  complete  the  INSERT  request 
attached  to  the  store.node.  It  Is  very  important  that  the 
order  in  which  the  database  Keys  are  accessed  from  tne 
request  buffer  match  the  order  of  the  attributes, 
MEMBER, set.typei,  In  the  INSERT  request.  The  INSERT  request 
Is  then  Issued.  Now,  because  we  have  not  accessed  this 
record  previously,  and  It  has  become  the  current  of  run 
unitf  store.rec  must  provide  a  buffer  to  hold  this  record  in 
case  a  GET  request  Is  Issued  Immediately  following  the  STORE 
request.  An  example  of  this  process  is  warranted  at  this 
point.  Suppose^  we  desire  to  store  the  SP  occurrence, 
S5/P6/700,   The  CODASYL  sequence  mlqht  bei 
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MOVE  'S5'  TO  SNO  IN  Sp 
MOVE  'P6'  TO  PNO  IN  SP 
MOVE  700  TO  OTY  lU    SP 
MOVE  'S5'  TO  SNO  IN  S 
MOVE  'P6'  TO  PNO  IN  P 
STOHE  SP 


The  first  three  moves  Initialize  the  new 
record's  data  values.  The  next  two  MOVE's  are  used  to  aid 
In  determining  which  S  and  p  occurrences  the  new  record 
belongs  to,  because  Its  set  Insertion  mode  was  declared  to 
be  automatic.  The  Kms  takes  this  Information  and  the  STOKE 
SP  statement,  and  produces  a  store.node  containing  the 
following; 


(DuDllcates  RETRIEVE  request) 

RETRIEVE  ((TYPE  e  SP)    and  (SNO  ■  55)  and  (PNO  a  P6)) 
(DDKEY) 

(List  of  RETRIEVES  to  get  owner  DBkEYs) 
RETRIEVE  ((TYPE  =  S)  and  (SNO  b  s5))  (OBKEY) 
RETRIEVE  ((TYPE  a  P)  and  (PNO  s  P6))  (DBKCY) 

(INSERT  request  for  new  record) 

INSERT  (<TYPE,SP>,<DBKEY,*»»>,<SN0,S5>r<PN0,P6>, 
<MEMBER,S-SP,**»»>,<MEMBER,P-SP, ♦♦»*>) 


We  assume,  for  the  saice  of  our  example, 
that  the  DBKEYs  for  the  owner  records  are  10(S)  and  12(P), 
and  that  the  DBKEY  of  the  new  record  Is  98,  i^e  also  assume 
that  there  Is  no  duplicate  SP  record  in  the  database.  So, 
when  store.rec  Issues  the  first  RETRIEVE,  the  request  buffer 
returned  Is  empty, 

Store.rec  then  proceeds  to  execute  the  list 
of  RETRIEVES  that  return  the  owner  OBKeYs  of  the  new  record. 
It  creates  a  request  buffer  for  the  first   RETRIEVE  on  the 
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list  and  Issues  the  request.  Once  the  first  request  Is 
executed,  a  buffer  Is  created  for  the  second  request,  and 
that  request  is  executed.  The  Issuance  of  these  retrieves 
produces  the  results  in  the  request  buffers  depicted  In 
Figure  25,  The  procedure  store.rec  now  tatces  the  new  dbkey 
value,  and  the  information  from  the  request  buffers  and 
completes  the  INSERT  request, 

♦---——♦ 
I  <  10  >  I 

I         I 

-♦■"•-•-•-•♦ 
Bufl 

I  <  12  >  I 
I         I 

+---•-•--♦ 
8uf2 

Figure  25:  Bufl  and  Buf2  After  Execution, 

The  final  form  of  the  INSERT  request  isi 

INSERT  (<TyPE,SP>,<DBKEY,98>,<SNO,S5>,<PNO,P6>, 
<MEMBER,S-SP,10>,<MEM8ER,P<.SP,12>) 

The  INSERT  request  is  then  issued  to  the  KDS,  If  no 
currency  suppression  list  is  attached  to  the  store^node,  the 
CIT  is  updated  to  reflect  a  change  in  the  S-SP  and  P-SP 
currency  as  well  as,  the  current  of  run  unit,  A  request 
buffer  is  also  created,  and  the  record  is  stored  in  the 
buffer.  As  one  can  see,  the  store.rec  procedure  can  be  a 
very  comprehensive  one. 
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(4)  Z&A  e&&Se  S£OcadU£A&.  The  ERASE  request  Is 
handled  by  the  procedure,  delete. recs.  If  the  type  of  the 
erase. node  Is  NULL,  then  delet.recg  proceeds  In  the 
following  inanner.  First,  a  request  buffer  is  created,  and 
the  RETRIEVE  request  attached  to  the  erase. node  Is  Issued  to 
the  KDS,  This  request  determines  if  the  record  being 
deleted  is  an  owner  of  a  non-empty  set.  If  the  request 
buffer  is  not  empty  after  execution  of  the  RETRIEVE,  then 
the  erase  fails,  and  we  have  an  error  condition.  If  the 
request  buffer  is  empty  after  execution  of  the  RETRIEVE, 
then  delete. recs  issues  the  DELETE  request  attached  to  tne 
erase. node.  This  request  deletes  the  current  record  of  the 
run  unit.  After  the  deletions,  delete. recs  updates  the  CIT 
by  setting  the  current  of  run  unit  indicator  to  NULL, 

Should  the  type  of  the  erase.node  be  ALL» 
we  have  a  different  sequence  of  events.  The  delete«recs 
procedure  must  create  request  buffers  for  each  RETRIEVE 
request  on  the  descendent  retrieve  list  In  tne  erase.node. 
It  must  then  issue  each  of  these  RETRIEVES  storing  the 
results,  returned  DBKEYs,  in  the  proper  request  buffer. 
After  the  lift  of  RETRIEVES  has  been  issued,  the  delete.recs 
procedure  then  completes  the  delete  requests  attached  to  the 
erase.node  and  issues  each  DELETE  request  to  the  KDS  for 
execution.  Once  again,  the  CIT  is  updated  to  reflect  the 
change  in  currency  i«e,,  current  of  set. types  become  NULL  as 
appropriate. 


90 


(5)  ZhA  C£Z  fiSfiCAdusA.  The  GET  request  Is 
handled  by  the  get.rec  procedure.  This  procedure  has  a 
relatively  easy  task.  It  simply  looks  at  the  type  of  the 
get.node,  examines  the  record.type  Involved,  and  retrieves 
either  the  entire  record  of  specific  fields  of  the  record 
from  the  request  buffer  Jn  which  the  record  resides.  The 
GET  request  operates  on  the  current  of  run  unit.  So,  the 
request  buffer  In  question  should  be  the  request  buffer 
containing  the  current  record  of  the  run  unit,  provided  tne 
current  record  of  the  run  unit  is  not  null.  Finally,  the 
reader  snould  note  that  with  each  of  the  above  procedures, 
deallocation  of  request  buffers  ^h^n  they  are  no  longer 
required,  is  also  an  Important  consideration  in  this 
process. 
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VI.   COUCLUSXQfiiS 

As  mentioned  in  the  Introduction,  the  conventional 
approach  to  database  system  development  has  resulted  In 
numerous  single-model,  single-language  systems  with  little, 
If  any,  flexibility  or  extensibility,  in  addition,  these 
systems  are  slow  compared  to  the  system  proposed  by  this 
research  effort.  Our  system,  the  multi-lingual  database 
system  fMLDS),  provides  an  alternative  to  the  development  of 
seperate  stand-alone  database  systems  wnlch  use  single  data 
models.  The  MLDS  *ill  bring  flexibility,  extensibility,  and 
efficiency  to  the  world  of  database  management.  The  mlds 
will  be  able  to  execute  transactions  written  in  any  of  four 
well-lcnown  and  important  data  lanquages,  namely,  DL/I,  SQL, 
CQDA5YL,  and  Oaplex, 

In  this  thesis,  we  have  presented  a  methodology  for 
supporting  network  database  management  within  the  MLDS, 
Specifically,  we  have  provided  a  data  model  transformation 
strategy,  and  a  data  language  translation  strategy  for  the 
network  data  model  and  the  COQASYL  data  language, 
respectively,  we  have  presented  a  design  specification  for 
the  kernel  mapping  system  (KMS)  to  be  used  in  the  CODASYL 
Interface,  A  discussion  of  the  concepts  involved  and  the 
data  structures  necessary  for  the  interface  to  work  properly 
has  also  been  presented. 
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One  of  the  deslqn  goals  of  this  project  was  to  make  the 
Interface  as  compatible  as  possible  with  the  designs  of  the 
DL/I  and  SOL  Interfaces  In  order  to  fully  utilize  existing 
software.  The  Daplex  Interface  is  not  mentioned  here, 
because  it  Is  being  developed  in  parallel  with  the  CODASYI. 
Interface,  By  pursuing  this  goal,  we  also  eliminate  the 
need  for  changes  in  the  mbds  and  the  A8DL,  Thus,  it  is 
recommended  tnat  the  implementation  of  the  CODASYL  interface 
follow  closely,  the  Implementations  of  the  DL/I  and  SWL 
Interfaces,  The  ImplementorCs)  should  pay  particular 
attention  to  any  commonalities  between  funtlons  and  data 
structures, 

we  feel  that  the  work  presented  herein  is  sufficient  for 
implementation  of  the  CODASYL  Interface,  All  that  remains 
Is  for  the  code  to  be  written,  and  placed  in  the  host 
computer.  Once  the  CODASYL  interface  and  the  Oaplex 
Interface  have  been  completely  implemented,  the  system 
Should  be  tested  as  a  complete  system  for  projected 
efficiency,  effectiveness,  and  responsiveness  Co  user  needs. 
It  is  anticipated  that  this  research  and  development  effort 
will  ultimately  result  In  a  new  era  for  database  management 
that  will  allow  for  Increased  productivity  and  profitability 
in  the  marketplace. 
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APPENDIX  -   THE  KMS  PROGRAM  SPECIFIC  A  TIOSS 

Currency  Indicator  Table 
References  made  in  the  following  specification  to  CIT  refer  to  the  Currency  Indicator  Table. 
This  table  consists  of  structures  that  hold   information  identifying  the  current  record  of  record- 
type,  set-type,  and  run-unit  (run-unit  is  the  application  program  being  run).  The  following  is  the 
proposed  structure  for  this  table  jRef.  13]. 
struct    CIT 

{ 

struct    RUN-UNIT  *run; 

struct    rec-type-node      *next-rec-type; 
struct    set-type-node     *next-set-type; 
} 

struct    RUN-UNIT 

{ 
char    rec-type(      ]; 
int     dbkey; 

} 

For  each  record  type  in  schema: 
struct    rec-type-node 

{ 
char  typ^l     ]; 

int  dbkey; 

struct  rec-type-node     *next-rec-type; 

) 


For  each  set  type  in  schema: 
struct    set-type-node 

{ 

boolean  OWNER; 

char  TYPE(     ]; 

int  dbkey; 

char  memberj     ]; 

char  owner(     ]; 

int  owner-dbkey; 
struct  set-type-node     *  next-set-type; 
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%{ 

boolean:    first-move  -  TRUE  /*  flag  for  MOVE  operation  */ 

boolean:    first-time        /*  general  purpose  flag  */ 

boolean:    sys-fiag-value  /*  boolean  value  of  system  fiags  */ 

ptr:    curr-temp-rec  /*  ptr  to  last  record  added  to  move-list  */ 

ptr:    curr-temp-item        /*  ptr  to  next  item  node  to  be  added  to 

record-template  node  of  movelist  */ 
list:  suppression-list     /*  list  of  record  types  and/or  set  types  */ 

for  which  currency  updates  are  suppressed  */ 
list:  select-list  /*  list  of  data  items  used  for  record  section  */ 

list:  connect-list  /*  list  of  sets  to  which  current  of  run 

unit  is  to  be  connected  or  disconnected  */ 
list:  tgt-list  /*  list  of  attribute  names  to  be  accessed  */ 

list:  move-list  /*  list  of  record  templates  used  with 

MOVE  statement  */ 
list:    curr-non-dup-list  /*  list  of  data  items  for  which  duplicates 

are  not  allowed  in  current  record-type  */ 
int:    level-number  /*  level  of  data  item  in  record  types  */ 

char:    member-type  /*  string  variable  to  hold  a  name  */ 

%) 
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start    statement 

statement:  ddl-statement 
I  dml 


dml:  dml-statement 
I  dml  dml-statement 


ddl-statement:  schema-defn    record-list    set-list 


schema-defn:  SCHEMA  NAME  IS  schema-name  SEMI-COLON 

{ 

locate  db-id  schema  header  node 

if  (db  names  do  not  match) 
print  ("Error-given  db-name  doesn't 

match  name  in  file") 
perform  y y error () 
return 

end-if 

initialize  db-key  /*  starting  value  is  1  */ 

} 


record-list:  record-desc 

{ 

set  db-id  node  ndn-first-rec  ptr 

} 
I  record-list    record-desc 

{ 

connect  successive  record  nodes 

} 


record-desc:  record    data-item-list 

{ 

curr-non-dup-list  —  NULL 

} 


record:  RECORD    NAME   IS 

{ 

allocate  and  init  a  new 

record  node  (NREC-NODE) 

allocate  curr-non-dup-list 

db-id- node  ndn-num-rec+  + 

} 
record-spec 
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record-spec;  record-type 

{ 

if  (record-type  not  defined  yet) 

copy  record-type  to  current 
record  node  (NREC-NODE) 

make  this  the  current  record  node 
end-if 
else 

print  ("Error-'record-type'  record 
doubly  defined") 

perform  yy error () 

return 
end-else 

} 

SEMI-COLON    duplicates-list 


set-list:  empty 
I  set-desc 

{ 

set  db-id  node    ndn-first-set  ptr 

} 
I  set-list  set-desc 

{ 

connect  successive  set  node(s) 

) 


set-desc:  set-desig    owner-spec    member-spec 


set-desig:  SET  NAME  IS 

{ 

allocate  and  init  a  new  set  node  (NSET-NODE) 
db-id-node  ndn-num-set+-|- 

} 

set-type 

{ 

if  (set-type  not  yet  defined) 

copy  set-type  to  current  set  node  (nsn-name) 

establish  curr-set-ptr 
end-if 
else 

print  ("Error-'set-type'  set  doubly  defined  in  db") 

perform  yy  error  () 
end-else 

} 
SEMI-COLON 
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owner-spec:  OWNER  IS    aa    SEMI-COLON 


aa:  record-type 

{ 

if  (record-type  not  defined) 

print  ("Error-'record-type'  record  does  not  exist") 

perform  yyerror() 

return 
end-if 
else 

copy  record-type  to  current  set  node  (nsn-owner-name) 

locate  record-type  node 

nsn-owner(ptr)  =  record-type  node 
end-else 

} 
I  SYSTEM 


member-spec:  MEMBER  IS    record-type 

{ 

if  (record-type  not  defined) 

print  ("Error-'record-type'  record  does  not  exist") 

perform  yyerror() 

return 
end-if 
else 

copy  record-type  to  current  set  node  (nsn-member-name) 

locate  record-type  node 

nsn-member(ptr)  =  record-type  node 
end-else 

} 
SEMI-COLON  insert-clause  retention-clause 

{ 

alloc  set-select  node 

} 
set-select-clause  SEMI-COLON 


duplicates-list:  empty 

I  dupl  SEMI-COLON 


dupl:  duplicate-spec 
I  dupl    duplicate-spec 


duplicate-spec:  DUPLICATES  ARE  NOT  ALLOWED  FOR  item-spec 
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item-spec:  item-name 

{ 

alloc  new  non-dup  node 

copy  item-name  to  non-dup  node 
add  non-dup  node  to  curr-non-dup-list 

} 
I  item-spec  COMMA  item-name 

{ 

alloc  successive  non-dup  nodes 

copy  successive  item-names  to  non-dup  nodes 
add  successive  non-dup  nodes  to  curr-non-dup-list 

} 


data-item-list:  item-desc 

{ 

connect  new  attr-node  to  record-node 

} 
I  data-item-list  item-desc 

{ 

connect  successive  attr-node(s)  to  record-node 

} 


item-desc:  level-num 

{ 

allocate  and  init  a  new  attr-node  (NATTR-NODE) 

NATTR-NODE  nan-level-num  =  level-number 

record-node  nrn-num-attr-|-  + 

} 
data- item-desc 

{ 

if  (nan-level-num  =  level  number  of  current  attribute  node) 

connect  new  attr  node  to  current  attr  node 

if  (nan-level-number  >  1) 
connect  nan-parent  ptr  of  new  node 

end-if 
end-if 
else  if  (nan-level-number  >  level  number  of  current  attr  node) 

connect  nan-child  ptr  of  current  attr  node  to  new  attr  node 

connect  nan-psirent  ptr  of  new  attr  node  to  current  attr  node 
end-else- if 
else 

locate  last  attr  node  with  same  level  number 

set  that  node's  nan-next-attr  ptr  to  the  new  attr  node 

update  current  attr  pointer 
end-else 

} 
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data-item-desc:  item-name 

{ 

copy  item-name  to  attr-node  (NATTR-NODE) 
if  (item-name  not  on  curr-non-dup-list) 

attr-node  nan-dup-flag   -  1 
end-if 

} 
SEMI-COLON    data-type    PERIOD 


level-num:  empty 

{ 

level-number  =1     /*  default  value  */ 

} 
I  INTEGER 

{ 

level-number  =  INTEGER 

} 


data-type:  CHARACTER  INTEGER 

{ 

attr-node  nan-lengthl  =  INTEGER 

attr-node  nan-length2  =  0 

attr-node  nan-type  =  'c' 

} 
I  FIXED  INTEGER 

{ 

attr-node  nan-lengthl  =  INTEGER 
attr-node  nan-length2  =  0 
attr-node  nan-type  =  'i' 

} 
I  FIXED  INTEGER 

{ 

attr-node  nan-lengthl  =  INTEGER 

} 
INTEGER 

{ 

attr-node  nan-length2  =  INTEGER 

attr-node  nan-type  =  'P 

} 
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insert-clause:  INSERTION  IS  Al'TOMATIC 

{ 

set-node  nsn-insert  =  'a' 

} 
I  INSERTION  IS  MANUAL 

{ 

set-node  nsn-insert  =  'm' 

} 


retention-clause:  RETENTION  IS  FIXED 

{ 

set-node  nsn-retent  =  T 

} 
I  RETENTION  IS  MANDATORY 

{ 

set-node  nsn-retent  =  'm' 

} 
I  RETENTION  IS  OPTIONAL 

{ 

set-node  nsn-retent  =  'o' 

} 


set-select-clause:  empty 

{ 

set-node  nsn-select  =  'o' 

} 
I  SEMI-COLON  SET  SELECTION  IS  BY   set-select-spec 


101 


set-select-spec:  VALUE  OF  item-name  IN  record-type 

{ 

if(valid-attr(item-name,record-type)) 

copy  'v'  to  set-select  node  select-mode 
copy  item-name  to  set-select  node  item-name 
copy  record-type  to  set-select  node  record  1 
copy  BLANK  to  set-select  node  record2 

end-if 

else 
print("Error- 'item-name'  not  valid  for  'record-type'") 
perform  yy error () 
return 

end-else 

} 
I  STRUCTURAL  item-name  IN  record-type 

{ 

if  (valid-attr  (item-name, record-type)) 

copy  's'  to  set-select  node  select-mode 

copy  item-name  to  set-select  node  item-name 

copy  record-type  to  set-select  node  record  1 

end-if 

else 
print("Error-'item-name'  not  valid  for  'record-type'") 
perform  yyerror() 
return 

} 

EQ  item-name  IN  record-type 

i  .        . 

if(previous  item-name  equals  this  item-name) 

if  (valid-attr  (item-name, record-type)) 

copy  record-type  to  set-select  node  record2 

end-if 

else 

print("Error- 'item-name'  is  not  valid  for  'record-type'") 

perform  y y error  () 

return 

end-if 

eke 

print("Error-'item-name'  items  do  not  match") 

perform  yy  error  () 

return 

end-else 

} 
I  APPLICATION 

{ 

copy  'a'  to  set-select  node  select-mode 

copy  BLANK  to  recordl,  record2,  item-name 
} 


102 


dml-statement:  set-flag 
move 
get 
find 
store 
connect 
disconnect 
erase 
modify 

perform-loop    /*  not  designed  */ 
if-then  /*  not  designed  */ 


set-flag:  MOVE  f-value  TO  f-name 


f-value:  YES 

{ 

sys-flag-value  =  TRUE 

} 
I  NO 

{ 

sys-flag-value  =  FALSE 

} 


f-name:  EOF 

{ 

eof  =  sys-flag-value 

} 
I NOTFOUND 

{ 

notfound  =  sys-flag-value 

} 
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/*  The  MOVE  statement  is  a  COBOL  assignment  statement  that  assigns  a  */ 
/*  value  to  a  particular  data  field  in  a  record  template.  We  use  a     */ 
/*  list  structure  for  this  purpose.  */ 

move:  MOVE  item-value 

{ 

if  (first-move  =  TRUE) 

alloc  and  init  move-list 

first-move  =  FALSE 
end-if 

create  new  data-item-node 

copy  'item-value'  to  value  field  in  data-item-node 
establish  curr-temp-item  pointer 

} 
TO  item-name 

{ 

copy  'item-name'  to  name  field  in  data-item-node 

} 
IN  record-type 

{ 

if  (item-name  not  in  record-type  for  current  schema) 

perform  error (2) 

return 

end-if 

else  if  ('record-type'  node  on  move-list) 

connect  curr-temp-item  to  record-template  node 

end-else- if 

else 

create  new  record-template  node 

copy  'record-type'  to  name  field  of  record-template  node 

connect  curr-temp-item  to  record-template  node 

add  record-template  node  to  move-list 

update  curr-temp-rec  pointer 

end-else 


/*  The  GET  statement  takes  the  entire  current  record  of  the  run  unit  */ 
/*  or  specified  data  fields  of  the  current  record  of  the  run  unit       "*/ 
/*  and  returns  the  values  to  the  user.  */ 

get:  GET 

{ 

alloc  and  init  new  'get'  node 

select-list  =  NULL    /*  reset  select-list  */ 

} 
mm 
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mm:  item-list  IN  record-type 

{ 

if  ('record-type'  is  not  equal  to  CIT. RUN-UNIT, type) 
perform  error (3) 
return 
end-if 
else 
get-type  =  ITEMS  in  get  node 
copy  record-type  to  get  node 
for  (each  data-item  on  item-list) 
if  ('data-item'  is  not  defined  for  record-type) 
perform  error(2) 
return 
end-if 
else  /*  create  pseudo  tgt-list  */ 

copy  data-item  to  get  node 
end-else 
end-for 
end-else 

} 
I  record-type 

{ 

if  ('record-type'  is  not  equal  to  CIT.RUN-UNIT.type) 

perform  error (3) 

return 
end-if 
else 

get-type  =  RETURN-ALL  in  get  node 

copy  'record-type'  to  get  node 
end-else 

} 
I  empty 

{ 

get-type  =  RETURN-ALL  in  get  node 

copy  CIT.RUN-UNIT.type  to  get  node 
} 

/*  The  FIND  statements  establish  the  current  of  run  unit,  record  type,  */ 
/*  and  set  type.  */ 

find:  FIND    record-selection-expr   curr-suppression 
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/*  The  F'IND  ANY  means:  find  any  record  of  type  rerord-type  whose  */ 
/*  values  for  itennl  through  itemn  match  those  in  that  record's     */ 
/*  template  in  the  user  work  area.  */ 

record-selection-expr:  ANY  record-type 

{ 

if  ('record-type'  record-template  node  is  not 

on  move-list) 

perform  error(l) 

return 
else 

alloc  and  init  new  'find'  node 

find-type  =  ANY  in  find  node 

copy  record-type  to  find  node 

alloc  and  init  new  abdl-str 

alloc  and  init  new  tgt-list 

/*  begin  forming  a  RETRIEVE  request  */ 

copy  ";  RETRIEVE  ((TEMPLATE  =  'record-type')" 
to  abdl-str 
end-if 
select-list  =^  NULL 

} 

USING    item-list    IN    record-type 

{ 

if  ('record-type'  is  same  as  previous  'record-type') 

if  (any  data  item  on  select-list  is  not 

defined  for  record-type) 

perform  error(2) 

return 

end-if 

else 

create  tgt-list  item  for  all  attributes 

of  'record-type'  record 

for  (each  data  item  on  select-list) 

if  ('data-item'  not  on  move-list) 

perform  error (l) 

return 

end-if 

else 

get  'item-value'  from  move-list 

concat  "and  ('data-item'  —  'item-value')" 

to  abdl-str 

end-else 

end-for 

concat  ") ('tgt-list')  by  DBKEY]"  to  abdl-str 

connect  abdl-str  to  find  node 

end-else 

end-if 

else 

perform  error (6) 

return 

end-else 

} 
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/*  The  FIND  CURRENT  means:  Make  the  current  of  set-type  the  current  */ 
/*  record  of  the  run  unit.  */ 

I  CURRENT  record-type  WITHIN  set-type 

{ 

if  (CIT. set-type. TYPE  is  not  equal  to  'record-type') 

perform  error(7) 

return 
end-if 
else 
/*  current  of  run-unit  becomes  current  of 'set-type'  */ 

alloc  and  init  new  'find'  node 

find-type  =  CURRENT  in  find  node 

copy  record-type  to  find  node 

copy  set-type  to  find  node 

copy  CIT. set-type. dbkey  to  find  node 
end-else 

} 

/*  The  FIND  DUPLICATE  means:  Find  the  first  record  in  the  current  set-  */ 
/*  type  occurrence  whose  value  for  iteml  through  itemn  matches  those     */ 
/*  for  the  same  items  in  the  current  set-type  occurrence,  not  the  UWA    */ 
/*  record  template.  This  implementation  assumes  the  records  being  re-    */ 
/*  quested  are  already  in  a  buffer.  */ 

I  DUPLICATE  WITHIN  set-type 

{ 

alloc  and  init  new  'find'  node 

find-type  =  DUPLICATE  in  find  node 

copy  set-type  to  find  node 

select-list  =  NULL    /*  reset  select-list  */ 

} 
USING  item-list  IN  record-type 

{ 

if  ((record-type  is  not  CIT.set-type.TYPE)  or 

(record-type  is  not  CIT. set-type. member)) 
perform  error(8) 
return 
end-if 
else 
copy  record-type  to  find  node 
for  (each  data-item  on  select-list) 
if  (any  data-item  on  select-list  is  not 
defined  for  record-type) 
perform  error (2) 
return 
end-if 
else  /*  create  a  pseudo  tgt-list  */ 

copy  data-item  to  find  node 
end-else 
end-for 
end-else 

} 
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/*  This  statement  means:  Find  the  FIRST,  LAST,  NEXT,  or  PRIOR  record-  */ 
/*  type  record  within  the  current  set-type  occurrence.  The  II  token      */ 
/*  takes  the  value  FIRST,  LAST,  NEXT,  or  PRIOR.  */ 

I   11    record-type  WITHIN  set-type 

{ 

if  ('record-type'  is  not  a  valid  member  type 
for  'set- type') 

perform  error (5) 

return 
end-if 
else 

copy  record-type  to  find  node 

copy  set-type  to  find  node 

/*  RETRIEVE  all  member  records  of  set  occurrence  */ 

alloc  and  init  new  abdl-str 

alloc  and  init  new  tgt-list 

copy  "[RETRIEVE  { 

(TEMPLATE  =  CIT.set-type. member)  and 
(MEMBER. set-type  =  CIT.set-type.owner-dbkey))" 
to  abdl-str 

create  tgt-list  for  all  attributes  of  member  record 

concat  "('tgt-list')  by  DBKEYj"  to  abdl-str 

connect  abdl-str  to  find  node 
end-else 

} 

/*  The  FIND  OWNER  means:  Find  the  owner  of  the  current  set-type  occurrence  */ 

I  OWNER  WITHIN  set-type 

{ 

alloc  and  init  'find'  node 

find-type  =  OWNER  in  find  node 
copy  set-type  to  find  node 
alloc  and  init  new  abdl-str 
alloc  and  init  new  tgt-list 

j*  form  RETRIEVE  request  */ 

copy  "[RETRIEVE  ((TEMPLATE  =  CIT.set-type.owner) 
and  (DBKEY  =  CIT.set-type.owner-dbkey))" 
to  abdl-str 

create  tgt-list  for  all  attributes  of  owner  record 

concat  "('tgt-list')j"  to  abdl-str 

connect  abdl-str  to  find  node 

} 
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/*  This  statement  means:  Find  the  first  record-type  record  within  the  */ 
/*  current  set-type  occurrence  whose  values  for  iteml  through  itemn     */ 
/*  match  the  values  found  in  the  record-type  template  in  the  UWA,  not  */ 
/*  the  values  in  the  current  of  set-type  as  in  the  FIND  DUPLICATE.       */ 

I  record-type  WITHIN  set-type  CURRENT 

{ 

if  ('record-type'  not  a  member  type  of  'set-type') 

perform  error(5) 

return 
end- if 
else 

alloc  and  init  new  'find'  node 

find-type  =  WITHIN  in  find-node 

copy  record-type  to  find  node 

copy  set-type  to  find  node 

alloc  and  init  new  abdl-str 

alloc  and  init  new  tgt-list 

/*  begin  forming  RETRIEVE  request  */ 

copy  "RETRIEVE  ((TEMPLATE  =  'record-type')  and 
(MEMBER.set-type  =  CIT. set-type. owner-dbkey)" 
to  abdl-str 
create  tgt-list  for  all  attributes  of  'record-type' 

record 
select-list  =  NULL     /*  reset  select-list  */ 
end-else 

} 
USING  item-list  IN  record-type 

if  (any  data-item  on  select-list  is  not  defined 
for  'record-type') 
perform  error (2) 
return 
end-if 

else  if  (any  data-item  on  select-list 
not  on  move-list) 
perform  error(l) 
return 
end-else- if 
else 
for  (each  data-item  on  select-list) 
get  'item-value'  from  move-list 
concat  "and  ('data-item'  —  'item-value') 
to  abdl-str 
end-for 

concat  ") ('tgt-list')  by  DBKEY]"  to  abdl-str 
connect  abdl-str  to  find  node 
end-else 

} 
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11:  FIRST 

{ 

alloc  and  init  new  'find'  node 

find-type  =  FIRST  in  find  node 

} 
LAST 

{ 

alloc  and  init  new  'find'  node 

find-type  =  LAST  in  find  node 

} 
NEXT 

{ 

alloc  and  init  new  'find'  node 

find-type  =  NEXT  in  find  node 

} 
PRIOR 

{ 

alloc  and  init  new  'find'  node 

find-type  —  PRIOR  in  find  node 
} 


curr-suppression:  LSQUARE  supp-expr  RSQUARE 
I  empty 


supp-expr:  SUPPRESS  UPDATE 
I  UPDATE  type-spec 


type-spec:  set-type 

{ 

add  set-type  to  suppression-list 

} 
I  type-spec  COMMA  set-type 

add  successive  set-types  to  suppression-list 
} 
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/*  This  statement  means:  Delete  the  current  record  of  the  run  unit,       */ 
/*  and  all  of  its  descendents  regardless  of  whether  they  are  owners  of  */ 
/*  other  sets.  */ 

erase:  ERASE  ALL  record-type 

{ 

if  ('record-type'  is  not  CIT.RUN-UNIT.type) 

perform  error (3) 

return 

end-if 

else 

alloc  and  init  new  'erase'  node 

erase-type  =  ALL  in  erase  node 

for  (each  set-type  in  schema) 

if  (CIT.set-type.owner-dbkey  =  CIT.RUN-UNIT.dbkey) 

member-type  =  CIT. set-type. member 

/*  form  RETRIEVE  to  get  member  records  */ 
alloc  and  init  new  abdl-str 
copy"[RETRIEVE(MEMBER.set-type  =  CIT.RUN-UNIT.dbkey) 

(DBKEY)  by  DBKEY]"  to  abdl-str 
connect  abdl-str  to  erase  node 

/*  erase  member  records  */ 

alloc  and  init  new  abdl-str 

copy" [DELETE( (TEMPLATE  =  'member-type')  and 

(DBKEY  =  ***)))"  to  abdl-str 
connect  abdl-str  to  erase  node 

/*  delete  all  descendants  of  member  records  */ 
perform  erase-all(member-type, erase  node) 
end-if 
end-for 

/*  delete  current  of  RUN-UNIT  */ 

alloc  and  init  new  abdl-str 

copy  "1DELETE( (TEMPLATE  =  'record-type')  and 

(DBKEY  =  CIT.RUN-UNIT.dbkey))]"  to  abdl-str 
connect  abdl-str  to  erase  node 
end-else 

} 
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/*  This  statement  means:  Delete  the  current  record  of  the  run  unit  if*/ 
/*  and  only  if,  it  is  not  the  owner  of  a  non-empty  set.  */ 

I  ERASE  record-type 

{ 

if  ('record-type'  is  not  ClT.RUN-UNIT.type) 

perform  error(3) 

return 
end-if 
else 

/*  erase  one  record  -  current  of  RUN-UNIT  */ 
alloc  and  init  new  'erase'  node 
erase-type  =  NULL  in  erase  node 

/*  form  RETRIEVE  to  see  if  'record-type'  is  */ 
/*  owner  of  non-empty  set  */ 

alloc  and  init  new  abdl-str 
copy  ";RETREIVE("  to  abdl-str 
first-time  =  TRUE 
for  (each  set-type  in  schema) 
if  ('record-type'  is  owner  type  of  set-type) 
if  (Tirst-time) 
concat  "(MEMBER.set-type  =  CIT.RUN-UNIT.dbkey)" 

to  abdl-str 
first-time  =  FALSE 
end-if 
else 
concat  "or  (MEMBER.set-type  =  CIT.RUN-UNIT.dbkey)" 
to  abdl-str 
end-else 
end-if 
end-for 

concat  ")(DBKEY)  by  DBKEY]"  to  abdl-str 
connect  abdl-str  to  erase  node 

/*  for  DELETE  request  */ 
alloc  and  init  new  abdl-str 
copy  "[DELETE  ((TEMPLATE  =  ClT.RUN-UNIT.type)  and 

(DBKEY  =  CIT.RUN-UNIT.dbkey))]"  to  abdl-str 
connect  abdl-str  to  erase  node 
end-else 

} 
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/*  The  STORE  means:  Create  a  new  record  in  the  database  using  values  */ 

/*  supplied  by  the  user  via  MOVE  statements,  for  the  data  items  of     */ 

/*  the  specified  record-type.    The  is  connected  to  all  sets  in  which  */ 

/*  INSERTION  IS  AUTOMATIC.    The  appropriate  occurrence  of  the  sets     */ 

/*  must  be  selected  before  the  new  record  can  be  connected.    This  is  */ 

/*  done  based  on  the  SET  SELECTION  clause  specified  in  the  database    */ 

/*  schema  definition  for  the  sets  in  question.  */ 

store:  STORE  record-type 

{ 

if  ('record-ype'  record  template  node  is  not  on  move-list) 

perform  error(l) 
return 
end-if 

alloc  and  init  new  'store'  node 
alloc  and  init  new  abdl-str 
copy  "[RETRIEVE  ("  to  abdl-str 
first-time  =  TRUE 

for  (each  data-item  in  schema  for  'record-type') 
if  (nan-dup-fiag  is  set) 
if  (data-item  in  move-list  'record-type'  record  template) 
get  data-item  value  from  move-list 
if  (first-time  =  TRUE) 
concat"(  (TEMPLATE  =  'record-type')  and 

('data-item'  =  'item-value'))"  to  abdl-str 
first-time  =  FALSE 
end-if 
else 
concat  "or  ((TEMPLATE  -  'record-type')  and 

('data-item'  =  'item-value'))"  to  abdl-str 
end-else 
end-if 
end-if 
end-for 

concat")(DBKEY)  by  DBKEY]"  to  abdl-str 
connect  retrieve  request  to  store  node 
alloc  and  init  new  abdl-str 

/*  Form  an  INSERT  request  */ 
copy"IINSERT  (<TEMPLATE,'record-type'>,<DBKEY,***>"  to  abdl-str 
for  (each  'data-item'  in  schema  for  'record-type') 
if  ('data- item'  not  on  move-list  for  'record-type') 
perform  error(4) 
return 
end-if 
else 
get  data-item  value  from  move-list 
concat", <'item-name','item-value'>"  to  abdl-str 
end-else 
end-for 
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/*  Now  determine  which  set  occurrences  the  new  record  belongs  to    */ 
/*  and  add  proper  attribute-value  pairs  to  the  INSERT  abdl-str  to  */ 
/*  indicate  set  membership.  The  following  FOR  loop  and  CASE  state-*/ 
/*  ment  fill  the  INSERT  abdl-str  with  the  proper  pairs.  */ 

for  (each  set-type  in  schema  in  which  'record-type'  is  a  member) 
case  (set  selection  mode)  of 

/*  set  selection  is  by  applicaton  */ 
a:  perform  by-application(INSERT  abdl-str) 

/*  set  selection  is  by  value  */ 
v:  perform  by-value(INSERT  abdl-str) 

/*  set  selection  is  by  structural  */ 
s:  perform  by-structural(INSERT  abdl-str) 

/*  no  set  selection  criteria  was  given  */ 
o:  perform  by-default(INSERT  abdl-str) 

end-case 
end-for 

concat  "]"  to  INSERT  abdl-str 
connect  INSERT  abdl-str  to  store  node 
alloc  and  init  suppression-list 

} 

curr-suppression 

{ 

connect  suppression-list  to  store  node 

} 
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/*  The  MODIFY  means:  Modify  the  entire  current  record  of  the  run  unit  */ 
/*  or  the  specified  data  items  in  that  record.    The  new  values  are       */ 
/*  supplied  by  the  user  via  the  UWA.  */ 

modify:  MODIFY 

{ 

select-list  =  NULL     /*  reset  select-list  */ 

} 

item-list  IN  record-type 

{ 

if  ('record-type'  is  not  current  of  run  unit) 
perform  error (3) 
return 
end-if 

if  ('record-type'  record-template  node  is  not  on  move-list) 
perform  error  (1) 
return 
end-if 

if  (any  data  item  on  select-list  not  defined  for  'record-type') 
perform  error(2) 
return 
end-if 
else 
alloc  and  init  new  'modify'  node 

locate  record-template  node  on  move-list  for  'record-type' 
for  (each  data-item  on  select-list) 
alloc  and  init  new  abdl-str 
/*  form  UPDATE  request  */ 

copy  "I  UPDATE  ((TEMPLATE  =  'record-type')  and 
(DBKEY  =  CIT.RUN-UNIT.dbkey))"  to  abdl-str 
get  'item-value'  from  move-list 
concat  "('data-item'  =  'item-value')]"  to  abdl-str 
connect  abdl-str  to  'modify'  node 
end-for 
end-else 

} 
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MODIFY  record-type 

{ 

select-list  =  NULL    /*  reset  select-list  */ 

if  ('record-type'  not  current  of  run  unit) 

perform  error(3) 

return 

end-if 

if  ('record-type'  record-template  node  is  not  on  move-list) 

perform  error(l) 

return 

end-if 

else 

alloc  and  init  new  'modify'  node 

for  (each  data-item  in  record-type) 

if  (data-item  not  on  move-list  for  'record-type') 

perform  yyerror(4) 

return 

end-if 

else 

alloc  and  init  new  abdl-str 

/*  form  an  UPDATE  request  */ 

copy  "1  UPDATE  ((TEMPLATE  =  'record-type')  and 

(DBKEY  =  CIT.RUN-UNIT.dbkey))  to  abdl-str 
get  new  'item-value'  from  move-list 
concat  "('data-item'  =  'item-value')]"  to  abdl-str 
connect  abdl-str  to  'modify'  node 
end-else 
end-for 
end-else 

} 
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/*  The  CONNECT  means:  Connect  the  current  record  of  the  run  unit  to  the  */ 
/*  current  occurrence  of  the  specified  set  type.    There  may  be  several    */ 
/*  sets  listed  in  the  statement.  */ 

connect:  CONNECT  record-type  TO 

{ 

if  ('record-type'  is  not  current  of  run  unit) 

perform  error (3) 

return 
end-if 
else 

alloc  and  init  connect-list 
end-else 

} 
set-type-list 

{ 

alloc  and  init  'connect'  node 
for  (each  'set-type'  on  connect-list) 
if  ('record-type'  is  not  a  member  type  record  for  'set-type') 
or  (INSERTION  is  not  manual) 
perform  error (5) 
return 
end-if 
else 
alloc  and  init  new  abdl-str 

copy  "[UPDATE  {(TEMPLATE  =  'record-type')  and 
(DBKEY  =  CIT.RUN-UNIT.dbkey)) 
(MEMBER. set-type  =  CIT.set-type.owner-dbkey)]" 
to  abdl-str 
connect  new  abdl-str  to  'connect'  node 
end-else 
end-for 

connect-list  =  NULL       /*  reset  connect-list  */ 
} 


set-type-list:  set-type 

{ 

add  'set-type'  to  connect-list 

} 
I  set-type-list    COMMA    set-type 

{ 

add  successive  'set-type' (s)  to  connect-list 

} 
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/*  The  DISCONNECT  means:  Disconnect  the  current  record  of  the  run  unit  */ 
/*  from  the  set  type  occurrence  that  contains  the  record.  */ 

disconnect:  DISCONNECT  record-type  FROM 

{ 

if  ('record-type'  record  is  not  current  record  of  run  unit) 

perform  error(3) 

return 
end- if 
else 

alloc  and  init  new  connect-list 
end-else 

} 

set-type-list 

{  .        . 

alloc  and  init  'disconnect'  node 

for  (each  set-type  on  connect-list) 
if  ('record-type'  is  not  a  member  type  record  for  'set-type') 
perform  error (5) 
return 
end-if 
else 
alloc  and  init  new  abdl-str 

copy  "[UPDATE  ((TEMPLATE  =  'record-type')  and 
(DBKEY  =  CIT.RUN-UNIT.dbkey)) 
(MEMBER. set-type  =  NULL)]" 
to  abdl-str 
connect  abdl-str  to  'disconnect'  node 
end-else 
end-for 
connect-list  =  NULL    /*  reset  connect-list  */ 

} 


perform-loop:  PERFORM  UNTIL  bb  EQ  cc 
I  END-PERFORM 


bb:  EOF 
I  NOTFOUND 


cc:  YES 
I  NO 
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item-list:  item-name 

{ 

put  item-name  on  select-list 

} 
I  item-list    COMMA    item-name 

{ 

put  successive  item  names  on  select-list 

} 


schema-name:  IDENTIFIER 


record-type:  IDENTIFIER 


set-type:  IDENTIFIER 


item-name:  IDENTIFIER 


item-value:  IDENTIFIER 
I  INTEGER 
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proc  error(err-code) 

/*  This  procedure  prints  error  messages,  causes  data  structures  to  */ 
/*  be  de-allocated,  and  causes  proc  yyerror  to  be  executed.  */ 


case  err-code  of 
1:  print("Error  -  must  initialize  'record-type'  record-template") 

2;  print("Error  -  'data-item'  not  defined  in  'record-type'") 

3:  print("Error  -  'record-type'  is  not  current  record  of  run  unit") 

4:  print("Error  -  attempting  to  modify  or  store  record  without 
giving  value  of  'data-item'") 

5:  print("Error  -  'record-type'  record  does  not  belong  to  'set-type'") 

6:  print("Error  -  record-types  specified  are  not  the  same") 

7:  print("Error  -  'record-type'  is  not  current  of 'set-type'") 

8:  print("Error  -  'record-type'  must  be  a  member  record  of  'set-type'") 

end-case 

perform  cleanup()     /*  free  data  structures  */ 
perform  yy error () 
return 
end-error; 
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proc  by-application{abdl-str) 

if  (set-node  nsn-insert  ='a'  )    /*  insertion  mode  is  automatic  */ 
concat",< MEMBER. set-type, ClT.set-type.owner-dbkey>"  to  abdl-str 

end-if 

else  /*  insertion  mode  is  manual  */ 
concat",<MEMBER.set-type,NULL>"  to  INSERT  abdl-str 

end-else 

end-by-application; 


proc  by-value{abdl-str) 

locate  data-item  node  in  schema  for  set-select  node  item-name 

in  set-select  node  recordl 
if  (nan-dup-flag  set) 
get  owner  record  type  of  set-type  from  schema 
if  (owner  record  type  node  not  on  move-list)  or 
(data-item  not  on  move-list) 
perform  error(4) 
return 
end-if 
else 
if  (set  node  nsn-insert  =  'a')    /*  automatic  insertion  */ 
get  data-item  value  from  move-list 
copy" [RETRIEVE( (TEMPLATE  =  owner-record-type)  and 

(item-name  =  'item-value'))  (DBKEY)]"  to  abdl-str 
connect  new  retrieve  request  to  store  node 
concat",<MEMBER. set-type, ***>"  to  INSERT  abdl-str 
end-if 
else    /*  manual  insertion  */ 

concat",<MEMBER.set-type,NULL>"  to  INSERT  abdl-str 
end-else 
end-else 
end-if  /*  nan-dup-flag  *  j 

end-by-value; 
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proc  by-structural{abdl-str) 

locate  data-item  nose  in  schenna  for  set-select  node  item-name 

in  set-select  node  recordi  record-type 
if  (nan-dup-flag  set) 
get  recordi  name  from  set-select  node  for  set-type 
if  ('recordi'  record  template  node  not  on  move-list)  or 
(data-item  not  on  move-list) 
perform  error(4) 
return 
end-if 
else 
if  (set-node  nsn-insert  =  'a')    /*  automatic  insertion  */ 
get  data-item  value  from  move-list 
get  record2  name  from  set-select  node  for  set-type 
copy"lRETRIEVE  ((TEMPLATE  -  record2  name)  and 

(item-name  =  item-value))  (DBKEY)"  to  abdl-str 
connect  new  retrieve  request  to  store  node 
concat",<MEMBER. set-type, ***>"  to  INSERT  abdl-str 
end-if 
else    /*  manual  insertion  */ 

concat",<MEMBER. set-type, NULL>"  to  INSERT  abdl-str 
end-else 
end-else 
end-if   /*  nan-dup-flag  */ 

end-by-structural; 


proc  by-default  (abdl-str) 

print("Warning  -  Attempting  to  store  a  record  with  no 
particular  set  selection  given.    Will  assume  'BY 
APPLICATION'") 
if  (set-node  nsn-insert  =  'a')    /*  automatic  insertion  */ 
concat",<MEMBER. set-type, CIT. set-type. owner-dbkey>" 
to  INSERT  abdl-str 
end-if 
else    /*  manual  insertion  */ 

concat",<MEMBER.set-type,NULL>"  to  INSERT  abdl-str 
end-else 

end-by-default; 
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proc  erase-all(record-type, erase  node) 

string     member-type; 

for  (each  set-type  in  schema) 
if  ('record-type'  is  owner  type  of  set-type) 
member-type  =  member  type  of  set-type 
/*  for  RETRIEVE  to  get  members  of  'set-type'  */ 
alloc  and  init  new  abdl-str 
copy  ";RETRIEVE(MEMBER.set-type  =  ***)(DBKEY)  by  DBKEY]" 

to  abdl-str 
connect  abdl-str  to  erase  node 
/*  delete  member  records  */ 
alloc  and  init  new  abdl-str 
copy  "|DELETE((TEMPLATE  =  'member-type')  and  (DBKEY  =  ***))]" 

to  abdl-str 
connect  abdl-str  to  erase  node 
/*  erase  descendants  of  member  records  */ 
erase-all(member-type, erase  node) 
end-if 
end-for 
return(erase  node) 

end-erase-all 
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